Endpoints shaped like the real services.
Your QuickBooks, Stripe or Plaid integration talks to Fictix with a new base URL and a Fictix project key. Responses follow each vendor's shape, so most client code works with little or no change.
Why 'shaped like' beats 'a generic API'
A generic test API forces you to write a translation layer you then have to trust. Fictix instead answers in each real service's response shape — QuickBooks looks like QuickBooks, Stripe like Stripe — so the code path you test is close to the code path you ship. Fidelity is approximate: the common resources and fields are there, not every endpoint and edge case of the real API.
What's covered
20 services answer with native-shaped endpoints today:
| Category | Services |
|---|---|
| Accounting | QuickBooks Online, Xero, NetSuite |
| Payments | Stripe, Square |
| Banking | Plaid, Mercury* |
| Spend / AP | Ramp, Brex*, BILL |
| Payroll / HR | Gusto |
| CRM / Commerce | HubSpot, Shopify |
| Productivity / Office | Slack, Asana, Airtable, Gmail*, Outlook, Google Drive, Excel |
* Read-only preview. Sage Intacct, Chase, DocuSign, Dropbox, OneDrive, ClickUp and Monday are execute-only: schema plus execution through the execute API, no native route yet. Every adapter is approximate fidelity, and the set grows.
How you point at it
Each project gets service-scoped endpoints on one base URL:
# base: https://api.fictix.ai/api/v1/orgs/{slug}/native/{service}/{path}
# auth: X-API-Key: <project key>
GET …/native/qbo/v3/company/{id}/query?query=SELECT * FROM Invoice
GET …/native/stripe/v1/charges
POST …/native/plaid/transactions/getChange the base URL and send your Fictix project key (X-API-Key). The vendor's own OAuth or Bearer token doesn't apply. Responses follow each vendor's shape, so most client code works with little or no change. To hand it off, share the company's console link and API base URL.
One company, seven systems that tie out
The adapters aren't independent fakes. A charge in the Stripe surface is the same economic event as the invoice in the QuickBooks surface and the deposit in the Plaid surface — one company's truth, projected into each API's shape. Books tie out across seven correlated systems: QuickBooks, Stripe, Plaid, Ramp, BILL, Gusto and NetSuite. The other services carry the same company's data but aren't reconciled. That cross-system coherence is the thing isolated sandboxes can't give you.
Questions
Do I need to rewrite my integration to test against Fictix?
Usually not. Change the base URL and send your Fictix project key (X-API-Key). Responses follow each vendor's shape, so most client code works with little or no change. Fidelity is approximate, so expect a few gaps.
Which services are supported?
20 native-shaped today: QuickBooks Online, Xero, NetSuite, BILL, Ramp, Stripe, Square, Plaid, Mercury, Brex, Gusto, HubSpot, Shopify, Slack, Asana, Airtable, Gmail, Outlook, Google Drive and Excel. Mercury, Brex and Gmail are read-only previews. Sage Intacct, Chase, DocuSign, Dropbox, OneDrive, ClickUp and Monday are execute-only.
Is data consistent across services?
Every service carries the same company. Books tie out across seven correlated systems (QuickBooks, Stripe, Plaid, Ramp, BILL, Gusto and NetSuite), so the Stripe charge, the QuickBooks invoice and the Plaid deposit are the same event. The other services aren't reconciled.