Integrations
AI integration services, with every write scope on the page
AI integration services are the half of an AI project that decides whether anything ever reaches a system of record. Every connector below lists the objects it reads, the scopes it asks to write, the auth model and the constraint you will design around.
- trigger: supplier invoice receivedmatched to its purchase orderrule
- auth: technical user, scopedauthorization objects onlyrule
- read: purchase order and supplierL3 · scoped writeagent
- write: park_invoice(invoice)inside the write scopeagent
- gate: AP approves the postingrouted with the match resultperson
- trigger: order webhook, HMAC verifiedrefund requestedrule
- auth: custom app, 24-hour tokenAdmin GraphQL scopesrule
- read: order and fulfilmentL3 · scoped writeagent
- gate: the store team approves the refundheld above the limitperson
- write: refund issued once approvedlogged against the orderagent
- trigger: issue webhook from the projectrenewed before it expiresrule
- auth: service account, OAuth 2.0granular project scopesrule
- write: create and link the issuenever deletesagent
- gate: the lead approves the sprint movetransition queuedperson
- done: transition, then a JQL sweepL4 · full workflowagent
- Connectors documented here
- 44
- Depth levels, graded per system
- 4
- Typical build, documented API
- 3 weeks
- Long-lived credentials we hold
- 0
The AI end of the connection
Models our AI integration services connect to your systems
OpenAIPublic API
Public API
GeminiPublic API
AWS BedrockIn your AWS account
Vertex AIIn your Google Cloud- OpenAIPublic API
- Public API
- GeminiPublic API
- AWS BedrockIn your AWS account
- Vertex AIIn your Google Cloud
Azure MLIn your Azure tenant
Mistral AISelf-hosted
OllamaOn your servers
Agent runtime
LlamaIndexRetrieval layer- Azure MLIn your Azure tenant
- Mistral AISelf-hosted
- OllamaOn your servers
- Agent runtime
- LlamaIndexRetrieval layer
Read this first
AI integration services: the model is the easy half
LLM integration services are now the well-trodden part of this work. A hosted model behind a product feature, retrieval over your own documents, a prompt layer and a set of evaluations: the patterns are public, the libraries are stable, and a competent team has something working inside a fortnight.
Where it stops is the moment the system has to do something rather than say something. Reading a record, changing a record and completing a workflow are three different projects, and at that point the work moves from prompts to permissions: scopes, service identities, rate limits, idempotency, retries, and an audit trail somebody will actually read during an incident.
So this page treats AI integration services as a catalogue of systems rather than a list of models. Each one is graded by the depth it reaches, costed by what it takes to build, and carries the constraint you will design around.
- Depth levels
- 4
- Read-only, read plus draft, scoped write, full workflow. Every connector is graded rather than described.
- Credentials
- Yours
- Issued by you, held in your secret manager, revocable from your side without contacting Meronym.
- Typical build
- 3 weeks
- For a documented REST or GraphQL API that Meronym has not built against yet.
- Connectors documented
- 44
- Across twelve categories, from CRM and ERP to healthcare records and automation platforms.
The vocabulary
"Integrates with" means four different things
Every vendor selling AI integration services on this search uses one phrase for all four, which is why three shortlisted suppliers can sound identical and quote differently by a factor of five. The gap between level two and level four is most of the project, most of the cost and nearly all of the risk, so every connector in the catalogue is labelled with the depth it reaches.
L10 in this catalogue
Read-only
The system can see the data and change nothing. Enough for retrieval, search and analysis. None of the forty-four here is limited to it, though licensing or a vendor review sometimes forces it.
L26 in this catalogue
Read + draft
The system prepares a reply, a record or a request that a person commits. The usual first release, and the one that gets through a security review fastest.
L328 in this catalogue
Scoped write
Writes inside a defined envelope, with approval gates above a threshold you set. Where most production work lives. It cannot transition a workflow it was not given.
L410 in this catalogue
Full workflow
Execution from trigger to finish, state transitions included, with reconciliation and a rollback path. Costs the most to build because the failure cases are the build.
01 · Catalogue
The integration catalogue, system by system
Filter by category or search. Every row states what our AI integration services need on that system: the objects read, the scopes requested to write, the auth model and how change is captured. It is a scope list, not a traffic report.
Nothing matches “”
A good share of every engagement is a system that is not on any vendor's list. Tell us what it is and we will say what it takes.
When it isn't in the listSalesforce
L4 · Full workflowCRM and sales · External client app, OAuth 2.0 client credentials, API-only integration user with a scoped permission set
Objects we read
- Lead
- Contact
- Opportunity
- Case
Write scopes we request
- update Lead status
- move Opportunity stage
- comment and close Case
- Change capture
- Change Data Capture, Flow and Platform Events, plus scheduled sweeps
The constraint to design around
The API allowance belongs to the whole org, not to one integration, so the agent listens through Change Data Capture instead of sweeping, and the five objects Change Data Capture watches by default are chosen with you.
HubSpot
L4 · Full workflowCRM and sales · Project-based app with granular scopes; a service key only where no webhooks are needed
Objects we read
- Contact
- Company
- Deal
- Ticket
Write scopes we request
- set Deal stage
- write properties
- reply in Conversations (as the agent's own user)
- Change capture
- App webhooks for property changes and inbox messages, plus workflow webhooks
The constraint to design around
A reply goes out only as a HubSpot user, and the same call writes to the customer or to the team, so the agent gets a user of its own and its scope keeps customer messages apart from internal comments.
Microsoft Dynamics 365
L4 · Full workflowCRM and sales · Application user for an Entra app with a custom security role; Business Central Entra application card with permission sets (never SUPER); one identity per job
Objects we read
- Lead and opportunity
- Case
- Business Central item
- Sales and purchase document
Write scopes we request
- update Lead and Opportunity fields
- add Case note, resolve (gated)
- draft quote or purchase invoice
- Change capture
- Asynchronous Dataverse webhooks on plug-in steps; Business Central webhooks renewed before their three-day expiry
The constraint to design around
Every limit is counted per user, application users included (6,000 requests in five minutes, one Dataverse search a second), and one Entra app gives one application user per environment, so a busy agent runs as one identity per job.
Zoho
L3 · Scoped writeCRM and sales · Self client for a dedicated user with a custom profile, scopes per named module with no delete, in your own data centre
Objects we read
- Lead
- Deal
- Contact
- Note
Write scopes we request
- update lead and deal fields
- add note
- create task
- Change capture
- CRM watch notifications renewed inside the one-week limit, workflow webhooks, and a sweep for changed records
The constraint to design around
A watch channel lasts a week at most and asking for longer silently gives one hour, so channels are renewed daily and checked by their token; API credits per 24 hours scale with edition and licences.
Zendesk
L4 · Full workflowService desk · OAuth client credentials on a dedicated agent user, resource scopes (API tokens retire in 2027)
Objects we read
- Ticket
- User
- Organization
- Help Center article
Write scopes we request
- comment (public flag set every time)
- set status and assignee
- open side-conversation (where the plan has it)
- Change capture
- Ticket event webhooks, plus a scheduled sweep because delivery is best effort
The constraint to design around
A public reply and an internal note are one write, split by a flag whose default follows the ticket, so every write sets it and the scope separates the two before an agent is given either.
ServiceNow
L4 · Full workflowService desk · OAuth 2.0 client credentials for a least-privilege integration user, pinned by REST API auth scopes
Objects we read
- Incident
- Request
- Knowledge
- CMDB CI
Write scopes we request
- add work note
- set state and assignment
- fulfil catalog task
- Change capture
- Business rules and Flow, plus scheduled jobs
The constraint to design around
CMDB writes go through ServiceNow's identification and reconciliation API with a role and data source of their own, so they need a different approval path from incident writes and usually a different sign-off owner.
Intercom
L4 · Full workflowService desk · Private app in your own workspace; a teammate your admin creates for the agent (the API cannot create one)
Objects we read
- Conversation
- Contact
- Company
- Help Center article
Write scopes we request
- reply
- assign and close
- set attributes
- Change capture
- Conversation and contact webhooks, deduplicated and ordered, with a sweep behind them
The constraint to design around
Every API reply names the teammate who wrote it, and one call writes either a customer reply or an internal note, so the agent replies as its own teammate and the connector gates the customer-facing path.
Gorgias
L3 · Scoped writeService desk · REST API key for a dedicated Gorgias user; the role is the ceiling (Observer for notes, Lite for replies, Basic for Shopify actions)
Objects we read
- Ticket
- Message
- Customer (with Shopify orders)
- Macro
Write scopes we request
- internal note (channel set every time)
- reply (gated per ticket type)
- set tags and status
- Change capture
- HTTP integrations on ticket events, plus a scheduled sweep because timeouts and error responses are not always retried
The constraint to design around
An API key acts with its user's full permissions and a message goes to the customer unless it is marked a note, so the agent's user starts as an Observer that cannot reply.
SAP
L3 · Scoped writeERP and finance · Communication arrangement on S/4HANA Cloud, technical user with scoped authorization objects on premise, through a route SAP endorses for agents
Objects we read
- Purchase order
- Supplier invoice
- Supplier
- Journal entry
Write scopes we request
- park invoice
- post within tolerance (gated)
- raise change request (master data governance)
- Change capture
- Business events on S/4HANA, IDocs by scheduled job on ECC
The constraint to design around
SAP's API policy lets AI agents that choose their own API calls reach SAP only through architectures SAP endorses, so the route is agreed with your SAP team before the role is designed.
NetSuite
L3 · Scoped writeERP and finance · OAuth 2.0 client credentials on an integration record, certificate mapped to a dedicated least-privilege role
Objects we read
- Vendor bill
- Purchase order
- Item receipt
- Saved search
Write scopes we request
- create Bill (Pending Approval)
- create journal for approval
- notes on the record
- Change capture
- SuiteScript user events, plus saved searches on a schedule
The constraint to design around
A new bill defaults to Approved and a journal posts on save, so the approval settings go on first and the integration role never holds an approval permission.
Odoo
L3 · Scoped writeERP and finance · Dedicated bot user with an API key on the JSON-2 API, rotated within three months, in groups holding only the listed access (Custom plan)
Objects we read
- Contact
- Sales order
- Invoice
- Stock quant
Write scopes we request
- draft quotation or invoice (unposted)
- move lead stage
- log chatter note
- Change capture
- Automation rules sending webhooks, plus scheduled checks on changed records
The constraint to design around
Each API call commits on its own and Odoo Cloud expects about one call a second with none in parallel, so every change is one Odoo method call that does the whole job, sent through a single queue.
QuickBooks
L3 · Scoped writeERP and finance · OAuth 2.0 app with the accounting scope, one-hour access tokens, the latest refresh token kept in your secret manager, reconnect before its five-year limit
Objects we read
- Customer
- Invoice
- Bill
- Report
Write scopes we request
- create Bill once approved
- create Invoice once approved
- attach document and note
- Change capture
- Signed webhooks (CloudEvents) plus Change Data Capture to catch misses
The constraint to design around
Writes are free but every read, query, report and change-data call is metered, and the free tier stops reads at 500,000 a month, so the agent listens by webhook, fetches changes in one call and caches; the API has no draft invoice, so approval comes before the write.
Stripe
L3 · Scoped writeCommerce and payments · Restricted API key tagged for an agent, Read or Write per resource, Stripe's approval rules on refunds and payouts
Objects we read
- Customer
- Payment
- Invoice
- Dispute
Write scopes we request
- refund within limit (gated)
- change subscription (gated)
- stage dispute evidence (unsent)
- Change capture
- Payment, invoice and dispute webhooks, signature-verified
The constraint to design around
A key that can refund can refund any amount up to the charge, so the ceiling lives in the agent's tool; no Stripe key reads a full card number, so the agent adds nothing to your PCI scope.
Shopify
L3 · Scoped writeCommerce and payments · Custom app in your own Dev Dashboard, Admin GraphQL scopes, 24-hour tokens, webhooks verified by HMAC
Objects we read
- Order
- Fulfilment
- Customer
- Inventory level
Write scopes we request
- refund within limit (gated)
- update fulfilment
- edit Product fields
- Change capture
- Order, fulfilment and inventory webhooks, with a reconciliation sweep
The constraint to design around
Shopify's order scope allows any refund, so the per-case limit lives in the agent's tool; and its API terms bar training AI on store data without the merchant's consent.
Adobe Commerce (Magento)
L3 · Scoped writeCommerce and payments · An integration limited to the resources on the list, every request signed with OAuth 1.0a (bearer use left off); IMS server-to-server on the SaaS edition
Objects we read
- Order
- Shipment
- Customer
- Product and stock
Write scopes we request
- add order comment
- create shipment with tracking
- refund by credit memo (gated)
- Change capture
- Adobe I/O Events on Adobe Commerce 2.4.4+, polling on updated_at on Open Source
The constraint to design around
An integration's token never expires, so Adobe stopped accepting it as a bearer token in 2.4.4 and the agent signs every request instead; the cloud-service edition has no integrations and signs in through Adobe's identity service.
Snowflake
L3 · Scoped writeData platforms · Service user with key pair or workload identity, never a password, role with SELECT on approved schemas
Objects we read
- Granted tables
- Views
- Semantic views
- Query history
Write scopes we request
- write to scoped schema
- trigger Task
- cache results
- Change capture
- Streams and Tasks, with notices to a queue on your own cloud
The constraint to design around
Row-access policies apply to the agent's queries but not to a search index, which answers with its owner's rights, so documents are indexed once per level of access.
Databricks
L3 · Scoped writeData platforms · Service principal, OAuth M2M, Unity Catalog grants
Objects we read
- Unity Catalog tables
- Volumes
- Search index
- Job status
Write scopes we request
- write to scoped table
- trigger Job
- call serving endpoint
- Change capture
- Job completion events and Delta table changes
The constraint to design around
Row filters and column masks apply to the agent's queries, but a search index cannot be built from a filtered table and has no row-level security of its own, so documents are indexed once per level of access.
BigQuery
L3 · Scoped writeData platforms · Service account with read roles per dataset and the project role queries need, workload identity federation instead of keys
Objects we read
- Datasets
- Authorised views
- Policy tags
- INFORMATION_SCHEMA
Write scopes we request
- write to scoped table
- run scheduled query
- call an approved model endpoint
- Change capture
- Scheduled queries with Pub/Sub notices, continuous queries where security allows
The constraint to design around
Authorised views and row-level security bound what it reads, but a dry run reports zero bytes on a row-secured table, so spend is held by a cap on bytes billed per query and a daily quota.
Microsoft Fabric
L3 · Scoped writeData platforms · Service principal in an allowed security group, Viewer on named workspaces with OneLake security roles, write access to one folder of its own
Objects we read
- Lakehouse table
- Warehouse table
- Semantic model
- Job run
Write scopes we request
- write to its own folder
- run pipeline (separate workspace)
- refresh named semantic model
- Change capture
- Job and OneLake events through an event stream you own, with polling of run history as the fallback
The constraint to design around
Row-level security written in SQL applies only through the SQL endpoint, and OneLake's own row rules skip Contributors and above, so the agent stays a Viewer wherever restricted data lives and writes only to a folder of its own.
PostgreSQL
L3 · Scoped writeData platforms · Login role that owns nothing, SELECT on approved schemas, timeout and connection limit on the role; IAM or Entra tokens on managed services, never MD5
Objects we read
- Approved tables
- Invoker views
- pgvector embeddings
- Column comments
Write scopes we request
- insert into the agent's schema
- call an approved function
- refresh a named materialised view
- Change capture
- Logical replication on a publication of named tables, or LISTEN/NOTIFY, with a scheduled sweep behind both
The constraint to design around
Row-level security skips table owners, superusers and BYPASSRLS roles, and a view reads with its owner's rights unless security_invoker is set, so the agent's role owns nothing it reads and its views are set to invoker.
MongoDB
L3 · Scoped writeData platforms · Database user of its own, custom role on named views and one collection, restricted to named clusters; AWS IAM, workload identity or X.509, never a shared password
Objects we read
- Views
- Named collections
- Vector search index
- Change stream
Write scopes we request
- insert into the agent's collection
- update fields on an allowlist (enforced in the connector)
- write run records
- Change capture
- Change streams on named collections, resumed by token, with a sweep for anything older than the oplog holds
The constraint to design around
Roles grant actions on whole databases or collections, never single documents or fields, so document limits live in views the agent reads without access to the collections behind them, and field limits live in the connector.
Elasticsearch
L3 · Scoped writeData platforms · API key with a role descriptor for named indices and an expiry, made by a narrow user; a second key for writes; never the superuser
Objects we read
- Indices
- Data streams
- Vector fields
- Mappings
Write scopes we request
- index into the agent's own index
- update by id on an allowlist (separate key)
- run an ingest pipeline
- Change capture
- Polling on a timestamp field, or a watch posting to a webhook
The constraint to design around
Document- and field-level security need a Platinum or Enterprise tier and are meant for read-only accounts, and a key made without a role descriptor copies its creator's rights and never expires, so the agent reads with one restricted key and writes with another.
Power BI
L2 · Read + draftBI and analytics · Service principal in an allowed security group, Viewer with Build on named models; the asker's delegated sign-in on models with row-level security
Objects we read
- Semantic model (DAX)
- Report
- Data source
- Refresh history
Write scopes we request
- start refresh (Write on that model only)
- post finding outside Power BI
- draft commentary for review
- Change capture
- Refresh completion polled by request ID, or a notice from the pipeline that loads the data
The constraint to design around
Power BI never applies row-level security to a service principal, and its query API refuses one on a model that uses it, so on those models the agent queries with the asking person's own sign-in.
Tableau
L2 · Read + draftBI and analytics · Connected app whose short-lived token names the asking user, smallest scopes; a dedicated Explorer user for scheduled work; personal access tokens for testing only
Objects we read
- Published data source
- Workbook and view
- Lineage
- Refresh status
Write scopes we request
- run extract refresh
- data-driven alert (Tableau Cloud)
- publish to the agent's own project
- Change capture
- Refresh webhooks, deduplicated, with a scheduled check because a webhook switches off after four failed deliveries
The constraint to design around
A connected app can sign in as anyone on the site and only its scopes limit it on the API, so the agent names the asking person, whose user filters then decide the rows, and never an administrator.
Looker
L2 · Read + draftBI and analytics · Each person's own OAuth sign-in for questions; a service account with a custom role, no admin rights and named models for scheduled work
Objects we read
- Explore
- Look
- Dashboard
- Query result
Write scopes we request
- schedule delivery
- save Look in its own folder
- draft commentary for review
- Change capture
- Scheduled deliveries to a webhook, plus checks kept inside the edition's monthly API allowance
The constraint to design around
Acting as another user needs the Admin role, and on Looker in Google Cloud regular users cannot be impersonated at all, so the agent answers through each person's own sign-in and access filters are checked Explore by Explore.
Slack
L4 · Full workflowComms · Your own internal Slack app, bot token, granular bot scopes
Objects we read
- Message
- Thread
- Channel
- User
Write scopes we request
- post and reply
- open Block Kit modal
- react
- Change capture
- Events API, slash commands and shortcuts, acknowledged within three seconds
The constraint to design around
Since May 2025 an app distributed outside Slack's directory reads channel history at one request a minute, 15 messages at a time, so the connector is built as your own internal app and reads threads when an event arrives.
Microsoft Teams
L3 · Scoped writeComms · Single-tenant bot in your tenant; resource-specific consent per team, Graph admin consent only for tenant-wide reads
Objects we read
- Channel message
- Chat
- Membership
- Meeting transcript
Write scopes we request
- post and reply
- send adaptive card
- notify proactively (where installed)
- Change capture
- Graph change notifications on renewed subscriptions, and bot events
The constraint to design around
Reading a meeting transcript takes an admin-consented permission, an access policy per organiser and a tenant setting left on, and channel meetings have no per-team route, so transcripts are agreed with your compliance owner, not at install time.
Twilio
L4 · Full workflowComms · Restricted API key, subaccount per environment; the Auth Token kept apart to check webhook signatures
Objects we read
- Call event
- Message event
- Recording
- Transcript
Write scopes we request
- place and answer Call
- send SMS or WhatsApp
- transfer with context
- Change capture
- Inbound call and message webhooks, signature-checked, plus status callbacks
The constraint to design around
US rules treat an AI voice as an artificial voice, so outbound calls and texts need consent on record, and every call names the business and says the agent is automated.
WhatsApp Business
L4 · Full workflowComms · Employee system user in your Meta business portfolio, granted only the named WhatsApp and Messaging accounts; webhooks verified with the app secret
Objects we read
- Inbound message
- Message status
- Template
- Customer profile
Write scopes we request
- reply inside the 24-hour window
- send approved template outside it
- hand over to a person
- Change capture
- Cloud API webhooks, signature-checked with the app secret
The constraint to design around
Outside the 24-hour window only approved templates may be sent, replies inside it are charged per message from 1 October 2026, and Meta's terms let WhatsApp chats train no model except one for your own use.
Microsoft 365
L3 · Scoped writeProductivity · Entra ID app registration, delegated or application permissions, narrowed to named mailboxes and sites
Objects we read
- Calendar
- SharePoint document
- Directory
Write scopes we request
- draft mail (sending is a separate grant)
- create Event
- write file or list item
- Change capture
- Graph change notifications and Power Automate flows
The constraint to design around
Application permissions reach the whole tenant until Exchange or SharePoint narrows them, and the narrowing does nothing while the unscoped grant stays, so consent and scoping are two decisions for your administrator.
Google Workspace
L3 · Scoped writeProductivity · OAuth client, or a service account with domain-wide delegation and a mailbox allowlist held in the connector
Objects we read
- Gmail thread
- Calendar availability
- Drive and Docs
- Directory
Write scopes we request
- draft mail, send gated in the connector
- create Event
- write Doc or Sheet
- Change capture
- Gmail watch renewed daily, Calendar watch channels, history checks for gaps
The constraint to design around
Google cannot limit domain-wide delegation to named people, only to kinds of data, so the connector keeps its own list of the mailboxes it may act for and logs every impersonation.
SharePoint
L3 · Scoped writeProductivity · Entra ID app with a certificate and Sites.Selected, each site granted by your administrator; the person's own sign-in when answering (Azure ACS app access retired 2 April 2026)
Objects we read
- Document library
- List item
- Metadata column
- Change log
Write scopes we request
- upload to named library
- update list item fields
- draft for review (labelled files via the person's sign-in)
- Change capture
- SharePoint list webhooks renewed before 180 days, plus scheduled change reads on libraries
The constraint to design around
A search run as the app returns what the app may see, not what the asker may, so answers to people use the person's own sign-in, where SharePoint intersects the site grant with their access; granting a site takes a full-control permission that stays with your administrator.
Box
L3 · Scoped writeProductivity · Server app your admin approves, client credentials as its own service account, app-only access, invited only on named folders
Objects we read
- File
- Folder
- Metadata
- Comment
Write scopes we request
- upload to a scoped folder
- set metadata
- add a comment or task
- Change capture
- Webhooks v2 on named folders, signature-checked, with an event-feed sweep behind them
The constraint to design around
A Box app with enterprise access and user tokens, or the as-user setting, can act as any user in the company, so the agent keeps to its own service account, invited on named folders, with every setting that lets it act as someone else left off.
Jira
L4 · Full workflowWork management · Service account with OAuth 2.0 client credentials, or a Forge app; granular scopes inside project permissions
Objects we read
- Issue
- Project
- Sprint
- Confluence page
Write scopes we request
- create and update Issue (never delete)
- transition
- comment
- Change capture
- Issue webhooks renewed before their 30-day expiry, plus JQL sweeps on a schedule
The constraint to design around
Cloud and Data Center authenticate differently, Cloud through a service account or a Forge app and Data Center through a personal access token on a dedicated account, so the access design branches on day one.
ClickUp
L3 · Scoped writeWork management · OAuth app your admin creates, authorised by a dedicated limited-member user invited only to named Spaces; personal tokens for testing only
Objects we read
- Task
- List
- Comment
- Doc
Write scopes we request
- create and update Task
- set fields and Custom Fields
- comment and link duplicates
- Change capture
- Task webhooks registered by the agent's own user, HMAC-verified, plus a scheduled sweep because failed events are never resent
The constraint to design around
ClickUp tokens carry no scopes and do not expire, so the boundary is the agent's own limited-member user in the named Spaces, and its webhooks stop silently if that user is deactivated, so it is never a person's account.
GitHub
L3 · Scoped writeWork management · GitHub App on selected repositories, one-hour installation tokens, no admin, workflow or commit status permission
Objects we read
- Issue
- Pull request
- Repository contents
- Actions run log
Write scopes we request
- comment and label
- open pull request from its own branch
- request review (never merge)
- Change capture
- App webhooks verified by signature and answered within ten seconds, with a job that redelivers failures
The constraint to design around
The Contents permission that lets the agent push a branch also covers the merge endpoint, so merging is stopped by a ruleset requiring a person's approval, with the app off the bypass list and required checks pinned to your CI.
monday.com
L3 · Scoped writeWork management · OAuth app authorised by a dedicated user on named boards only, expiring OAuth 2.1 tokens, never a personal token
Objects we read
- Board
- Item
- Update
- Doc
Write scopes we request
- create and update Item
- change column values on the list
- post an update
- Change capture
- Board webhooks created with the app's token and checked by their JWT, plus one sweep after the 30-minute retry window
The constraint to design around
A Basic or Standard account gets 1,000 API calls a day, shared by every private integration it runs (Pro 10,000, Enterprise 25,000), so the agent listens to webhooks, asks for many items in one query and keeps a daily budget.
Workday
L2 · Read + draftHR and people · Agent System User per mode, registered in your record of agents, through Workday's agent gateway
Objects we read
- Worker
- Position
- Absence balance
- RaaS report
Write scopes we request
- submit time-off request
- complete onboarding task
- initiate business process
- Change capture
- Business process events and scheduled RaaS pulls
The constraint to design around
Every outside agent must be registered and send every call through Workday's agent gateway as its own agent user, and every write it makes starts a business process, so the agent drafts and submits and your approvers decide.
Epic
L2 · Read + draftHealthcare records · Backend app on Epic on FHIR, client credentials with a signed JWT and a JWK Set URL, client ID mapped by each health system to an Epic user of its own
Objects we read
- Patient
- Appointment
- Coverage
- DocumentReference (read)
Write scopes we request
- book Appointment (find-and-book, per visit type)
- hand off to a staff queue
- draft for staff to file (never a signed note)
- Change capture
- HL7 v2 feeds the health system sets up (ADT, appointment scheduling), plus scheduled FHIR reads by date
The constraint to design around
Each health system maps the agent to an Epic user of its own and decides which write APIs to enable, and today's information-blocking rules let it refuse a third party's writes, so the first release reads and drafts, one health system at a time.
Oracle Health (Cerner)
L2 · Read + draftHealthcare records · System account from code Console registered to the health system (system access is for the covered entity or its business associates), provisioned against its tenant by service request
Objects we read
- Patient
- Appointment
- Coverage
- DocumentReference (read)
Write scopes we request
- create Appointment as proposed (a request)
- send Communication to a staff pool
- draft for staff, outside the chart
- Change capture
- Scheduled FHIR searches, or HL7 v2 feeds from the site's interface engine
The constraint to design around
A document written through Oracle Health's API is filed as final, with no draft status, so the agent keeps drafts outside the chart and writes requests and staff messages instead.
Zapier & n8n
L3 · Scoped writeAutomation platforms · Authenticated n8n webhooks (header or JWT, allowlisted), Zapier webhook URLs kept as secrets, per-workflow keys, never an n8n instance API key
Objects we read
- Webhook payload
- Table record
- Run history
- Step data
Write scopes we request
- trigger workflow
- return structured result (n8n; a Zap posts back)
- write to data store
- Change capture
- Webhook steps and scheduled runs
The constraint to design around
A Zapier webhook always answers 200, even before the Zap runs or after it is off, so every call the agent makes waits for a callback before it counts; production actions get a direct connector.
Power Automate
L3 · Scoped writeAutomation platforms · Agent's own Entra app, the only caller each flow's HTTP trigger admits; flows owned by a service principal (capacity licence where premium)
Objects we read
- Flow run history
- Flow answer
- Approval outcome
- Dataverse row
Write scopes we request
- start flow with inputs
- raise approval (people decide)
- write Dataverse row
- Change capture
- Flows call the agent as a step, or the agent starts a flow; failed runs read from run history
The constraint to design around
A data policy decides whether the agent can call a flow at all, and Microsoft advises keeping the HTTP trigger out of the business group in the default environment, so the agent's flows live in an environment of their own, beside the connectors they use.
UiPath
L3 · Scoped writeAutomation platforms · Confidential external app, client credentials with the default scope only and a role in each named folder (explicit Orchestrator scopes would reach every folder)
Objects we read
- Queue item
- Job and output
- Process
- Asset (non-secret)
Write scopes we request
- add queue item
- start job with input arguments
- set priority and deadline
- Change capture
- Signed Orchestrator webhooks on job and queue item events, plus each job read by ID, because undelivered events are lost
The constraint to design around
A job the agent starts runs under the robot's own Windows account, not the agent's, and Orchestrator's explicit scopes open every folder in the tenant, so the app holds folder roles only and starts only processes whose robot access you have approved.
MuleSoft
L3 · Scoped writeAutomation platforms · Its own client app with an approved contract per API instance, credentials in headers or OAuth through your identity provider; a scoped connected app only for Anypoint MQ
Objects we read
- API specification
- API response
- Client app usage
- Rate-limit headers
Write scopes we request
- call approved write operations
- acknowledge its own queue
- log each action
- Change capture
- A Mule flow forwarding events, or the agent's own Anypoint MQ queue
The constraint to design around
Omni Gateway meters every request it receives, a refused one included, and the tier's quota counts per replica unless shared, so the agent has its own client app and tier and listens for events instead of polling.
02 · Anatomy
How one integration gets built
Every connector built under our AI integration services has the same six parts. Two of them are the reason a straightforward API integration takes three weeks rather than three days, and neither of the two is the part people budget for. The days beside each part are typical for a documented API.
A14 days
Auth and credentials
Service identities, key rotation and the least-privilege scope list your security team signs. The longest pole on most engagements, for organisational rather than technical reasons: the API is ready before the approval is.
A22 days
Typed tool schema
Each operation exposed as a typed function with validation, so a model cannot invent a field or submit a value the system will reject.
A32 days
Change capture
Webhooks where they exist, polling with watermarks where they do not, and a backfill path that does not double-count when it is run twice.
A44 days
Rate limits and retries
Backoff, circuit breaking, idempotency keys and a cost ceiling. The second part nobody budgets for: it is invisible until the day volume doubles.
A52 days
Sandbox harness
A dry-run mode and a seeded test environment, so write paths are exercised hundreds of times before one of them touches production.
A61 day
Observability
Per-call traces, an error taxonomy, and an alert that names the connector and its owner rather than saying that an integration failed.
03 · Access posture
What your security review will ask about AI integration services, answered
Write access to a system of record is the moment an AI project turns into a security review, and enterprise AI integration usually stalls there rather than at the model. Meronym arrives with the scope list, the service-identity model and the revocation path already drafted, so the first meeting is about specifics rather than principles.
Every connector runs under credentials you issue, held in your secret manager, inside your cloud account. You can revoke any of them without contacting us.
| Question | Answer |
|---|---|
| Where do the credentials live? | In your secret manager, in your cloud account. Meronym holds no long-lived credentials for your systems. |
| What exactly can it write? | Only the scopes on the connector row, agreed in writing before build starts. Anything outside them fails closed rather than degrading quietly. |
| Can we revoke access ourselves? | Yes, unilaterally and without notice. Nothing requires Meronym to be in the loop to shut a connector off. |
| Is every action logged? | Actor, inputs, outputs, timestamp and the reasoning behind the decision, retained to your policy and queryable by case. |
| How is personal data handled? | Classified at ingestion and redacted before it reaches a model where your policy requires it. It is not persisted outside your boundary. |
| What about prompt injection through retrieved content? | Retrieved content is never treated as instructions, and the separation is tested with an adversarial suite as part of every release. |
| Who signs off the scope list? | Your system owner and your security lead, before build starts. Meronym does not begin write work on a verbal agreement. |
04 · Custom connectors
When your system isn't in the list
Engagements often involve a system nobody has built against: a policy administration platform from 2009, an internal service with one endpoint, a mainframe extract that lands by SFTP at two in the morning. None of those is a special case and none of them is quoted as one. Here is what AI integration services cost for each shape.
Case 1
Documented API, not yet built against
A modern REST or GraphQL API that Meronym simply has not built against. Auth, schema, change capture and tests follow the same six parts as everything in the catalogue.
Typical$6k–$18k
Case 2
Legacy or partial API
SOAP, an undocumented endpoint, or an API that covers most of what you need and not the part you need most. Involves discovery and usually a conversation with the vendor.
Typical$8k–$35k
Case 3
No API at all
A database replica, a scheduled file exchange, or an extract somebody else built. We design the least fragile path available and monitor it harder than the rest.
Typical$10k–$53k
Case 4
Your own internal service
Your systems, where your engineers own the endpoint. The fastest of the four: we specify what we need and integrate against what you ship.
Typical$4k–$12k
The connector is yours, not rented
Every connector Meronym builds lands in your repository under your licence, with its tests and its sandbox harness. Reuse it on the next project, hand it to another supplier, or maintain it in-house. No per-connector fee and no runtime dependency on us.
Money
What AI integration services cost
AI integration services are priced by how many systems are in scope and how deep the agent goes in each, because those are the two things that actually move the number. Build and run are quoted separately so you can see which one you are committing to.
4–6 weeks
One system, read plus draft
Build $8k–$35k · Run cost modelled at your volume
A single documented API at L2. Retrieval, drafting and a human commit. The usual first release and the fastest route through a security review.
8–14 weeks
One system, scoped write
Build $16k–$82k · Run cost modelled at your volume
The same system taken to L3, with an approval gate above a threshold you set, idempotency and a rollback path.
3–6 months
Two to four systems
Build $26k–$153k · Run cost modelled at your volume
A workflow that crosses systems, so reconciliation between them becomes part of the build rather than an afterthought.
Set after scope
Five or more systems
Quoted after scope · Run cost modelled at your volume
Programme shape. Connectors land in waves, each one live before the next starts, with the scope list reviewed once rather than five times.
What moves the number
- Which SAP, which Jira, which Epic. ECC, S/4 on-premises and S/4 Cloud are effectively three different integrations, and the answer can change an estimate by a factor of three.
- Whether a full-copy sandbox exists. Write paths that cannot be exercised against representative data are quoted with a contingency, because they will find something.
- How long your own approval takes. This is the longest pole on most engagements and it is the one item on this list that Meronym cannot shorten.
- Whether writes are in scope or the first release is drafts only. The step from L2 to L3 is where the failure cases start being built.
- Whether the upstream API is documented, partially documented, or a vendor conversation waiting to happen.
05 · Sectors
Where our AI integration services get used
- InsurancePolicy administration and claims systems, where the FNOL path is the integration.
- BankingCore banking and case management, where the write scope is the whole negotiation.
- HealthcareRecords systems with a vendor review process measured in months, not weeks.
- ManufacturingERP and shop-floor systems, usually reached through a replica rather than an API.
- LogisticsCarrier and visibility platforms, where the data arrives and the quality is the project.
- RetailCommerce, inventory and payments, where refunds are the gated action everyone argues about.
- ProcurementPurchasing and supplier systems, where approval chains are configured per company.
- HRPeople systems that route every write through a business process by design.
Selected work
Three integrations, and what each one changed
- Financial advice · Three messaging providersA message arrives in under 2 seconds in most active conversations, down from 4 to 6One message model over three messaging providers, with an adapter for each, so campaigns, opt-ins and keyword rules behave the same whichever provider sends. An estimated 25 to 35% of the inconsistencies between providers went, in multi-provider testing.Read the case study
- Service businesses · Calls, WhatsApp, SMS and emailUpdating a lead record: 3 to 5 minutes down to under 60 secondsFour channels written to one record per lead in the sales CRM, so the rep who takes over sees the call summary, the messages and the next step in one timeline.Read the case study
- Law firms · Stripe payments and billingPayments synced in the background, built to end manual updates to client accountsStripe for client payments, advance financing and payouts, with each payment reconciled in the firm's financial model and real-time updates on payments and case actions.Read the case study
Who does the work
The squad on an integration engagement
Small, and two of the five seats are yours. In AI integration services the access review is the critical path, and it is not a path Meronym can walk for you.
| Role | Owns | Allocation |
|---|---|---|
| Integration engineer | The connector: auth, tool schema, change capture, retries, tests. | Set in scope |
| AI engineer | What the agent does with the connector, and the evaluations that gate each action. | Set in scope |
| Tech lead | The scope list, the failure design, and the review your team runs against both. | Set in scope |
| System owner, yours | The platform itself: sandbox, configuration, and what the agent may touch. | Set in scope |
| Security lead, yours | Approving the scope list and issuing the credentials. The longest pole on most builds. | Set in scope |
Read before you buy AI integration services
All guidesFAQs
What buyers ask about AI integration services before the security review
What are AI integration services?
AI integration services are the engineering that connects an AI system to the software a business already runs, so it can read the data those systems hold, take actions inside them and respond to events they raise. The AI part is the model; the integration part is the scopes, the service identity, the change capture, the retries and the audit trail. On most projects the second part is the larger one.
How much do AI integration services cost?
One system at read-plus-draft is $8k–$35k to build, one system at scoped write $16k–$82k, and two to four systems $26k–$153k. Five or more systems are quoted after scope, and the monthly run cost is modelled at your volume. The two things that move it are how many systems are in scope and how deep the agent goes in each. A single system at read-plus-draft is a different order of work from a workflow crossing four systems with write access in each, and the cost section above prices the four shapes separately.
How are LLM integration services different from AI integration services?
LLM integration services put a model behind a feature: retrieval over your content, a prompt layer, an evaluation set. That is the well-trodden half of AI integration services. Systems integration is what follows, when the model has to change something rather than say something, and that is where permissions, rate limits and idempotency start deciding the timeline.
Can you integrate with a platform that is not in the catalogue?
Yes. Our AI integration services cover anything with an API, webhooks, a file drop or a database we can reach. The section above prices four shapes, from a documented API with no connector yet through to a system with no API at all. The scoping, the security model and the shadow-then-graduate rollout do not change.
How long do AI integration services take for one system?
Typically about three weeks for a documented API, and four to six for a legacy or partial one. The variable is rarely the code. It is how long your own access review takes, whether a full-copy sandbox exists, and whether the upstream API is documented. The six parts in the anatomy section carry an effort estimate each.
Does the agent need administrator access to our system?
No. It gets a dedicated service identity with least-privilege scopes covering exactly the objects on its connector row. Anything outside that list is a human action, and the identity fails closed rather than falling back to a wider permission.
Who holds the credentials, and can we revoke them?
You issue them, they live in your secret manager inside your cloud account, and you can revoke any of them unilaterally without contacting Meronym. Nothing in the design requires us to be in the loop to switch a connector off.
What happens when the upstream API rate-limits or goes down?
Backoff and circuit breaking on the way out, idempotency keys so a retry cannot double-post, and an alert that names the connector and its owner. Work that cannot complete is queued or handed to a person with the reason attached, never dropped silently.
Do we own the connector after the project ends?
Yes. Every connector our AI integration services produce lands in your repository under your licence, with its tests and its sandbox harness, no per-connector fee and no runtime dependency on Meronym.
Do you use iPaaS or no-code automation tools?
For prototypes and low-risk, low-volume glue, sometimes, and the catalogue has a row for them. For production actions we build direct connectors instead, so autonomy, logging and permissions sit with you rather than with a third party you did not choose.
Send us the system name and the version
Most of the spread in an integration estimate comes from which deployment you are on, so one line gets you a real answer instead of a discovery call. We will come back with the depth we would build to, the scopes we would ask for, and what it takes.
A senior engineer replies within two business days, not a form.