Developer Reference

    API Documentation

    Everything you need to integrate with Gato Systems: REST references, FIX specifications, environment details, and authentication rules. Start with the guides below, then move into the endpoint-level reference for each product.

    How to start an integration

    Get credentials

    Every environment uses its own client ID and secret. Request a UAT pair from your integration contact, then exchange it for a bearer token.

    Call the sandbox

    Point your client at the UAT base URL first. Sandbox data is disposable, so you can replay onboarding and order flows as often as you need.

    Pass certification

    We review your request logs before enabling production. Expect a short checklist covering error handling, retries, and audit fields.

    Hosted references

    Account Opening API

    v1

    Digital account onboarding for individuals, joint accounts, and entities. Includes the request flow, field-level payload tables, and error codes for each endpoint.

    Product API portals

    The remaining product APIs live in our integrator portal. Each one carries its own environment matrix, sample payloads, and change log.

    FIX APISession setup, message types, order flow.Trading APIOrder entry, cancels, executions.Funding APIACH transfers and cash movement.Risk & Margin APIPre-trade checks and buying power.Corporate Actions APIAnnouncements and elections.

    Need access?

    API access is granted to licensed integrators. Tell us which products you plan to use and we will issue sandbox credentials plus a certification checklist.

    Visit the developer hub

    A working integration order

    Teams that ship quickly tend to follow the same five steps. Each one closes a category of problem before the next one starts.

    Step 1

    Map your flows

    List the actions your product needs: open an account, move cash, place an order, pull a statement. Each maps to one API. That list tells you which references to read and which you can skip.

    Step 2

    Wire auth once

    Build a single token helper that caches a bearer token and refreshes it before it expires. Every other call reuses it. Doing this first removes a whole class of intermittent failures later.

    Step 3

    Run one happy path

    Open a sandbox account, fund it, place a small order, and read the resulting records. One clean pass proves your plumbing before you add edge cases.

    Step 4

    Break it on purpose

    Send a bad payload, exceed a limit, and retry a write twice with the same key. Certification looks at how you behave when things fail, not just when they work.

    Step 5

    Go live

    Swap in production credentials and base URLs from config. Watch your first day of traffic closely, then widen volume once error rates look flat.

    Platform conventions

    The same rules apply across every Gato Systems API. Learn them once and each new product reference reads faster.

    Environments

    Every API runs in two places. UAT is the sandbox you build against. Production is the live venue-facing environment. Base URLs differ, and credentials never cross between them. Keep both sets in your secret store so a config change cannot point test traffic at live accounts.

    Authentication

    All REST calls use OAuth 2.0 client credentials. You post your client ID and secret, get a short-lived bearer token, and send that token on every request. Tokens expire, so cache one and refresh it before it lapses rather than minting a new token per call.

    Request format

    Requests and responses are JSON. Timestamps are UTC in ISO 8601 form. Money fields carry an explicit currency. Identifiers you send are echoed back so you can match a response to the record that created it.

    Errors and retries

    Errors return a stable code, a human-readable message, and the field that failed. Treat 4xx as a problem in your payload and 5xx as retryable. Retry with backoff, and always send your own idempotency key on writes so a repeat never books twice.

    Rate limits

    Each client key has a request budget per second. When you exceed it you get a 429 with a retry hint. Batch reads where an endpoint supports it, and spread bulk jobs over time instead of firing them in one burst.

    Versioning

    Versions are pinned in the path. We add fields without breaking you; we never remove or repurpose a field inside a version. Breaking changes ship as a new version with an overlap window so you can migrate on your own schedule.

    Developer Guide

    How the Gato APIs fit together

    This hub is the front door to every Gato Systems API. It explains how our platform is put together, what to build first, and where each endpoint reference lives.

    Our APIs cover the full trade lifecycle. You can open and fund an account, run pre-trade risk checks, route an order, follow the execution, and pull the records your compliance team needs. Each product is separate, so you only integrate what you use.

    Most teams start small. They open a sandbox account, place one order, and confirm the resulting records line up with what they expect. That single pass surfaces most integration questions in a day rather than a month.

    The sections above cover the shared rules. The sections below cover the order of work, the data you should log on your side, and the questions integrators ask us most often.

    • REST references hosted here cover request flow, field tables, and error codes.
    • FIX, Trading, Funding, Risk & Margin, and Corporate Actions live in the integrator portal.
    • Sandbox credentials are separate from production and never interchangeable.
    • Every write endpoint accepts an idempotency key so retries stay safe.
    • Audit fields on each record support CAT, CAIS, and internal supervision reviews.

    Read the reference for a product before you write code against it. The field tables tell you which values are required, which are conditional, and what a rejection means. That saves a round of certification comments later.

    If something in the docs is unclear or out of date, tell us. We keep the references in step with the running platform, and integrator feedback is how we catch the gaps.

    Keep your own request log from day one. Store the endpoint, the payload you sent, the response code, and the identifier we returned. When a certification question comes up, that log answers it in minutes.

    Plan for two environments in your own code as well. Read the base URL and the credentials from config, never from a constant in a source file. Teams that hard-code a URL are the teams that later point test traffic at live accounts.

    Which API should I start with?

    Start with Account Opening if you onboard clients, or Trading if you already hold accounts elsewhere. Both have sandbox flows you can run end to end in a day.

    Do I need FIX as well as REST?

    No. REST is enough for onboarding, funding, and lower-rate order flow. Choose FIX when you need session-based order entry, high message rates, or a venue standard your counterparties already use.

    How do I get sandbox credentials?

    Ask your integration contact, or reach us through the developer hub. Tell us the products you plan to use and we issue a UAT client ID, a secret, and a certification checklist.

    How long does certification take?

    Most teams pass in one or two rounds. We review your sandbox request logs for correct error handling, retry behavior, and complete audit fields, then enable production keys.

    What happens when an API changes?

    Additive changes ship in place. Breaking changes ship as a new pinned version with an overlap window, and the change log for each product records what moved.

    Is there a status page for the APIs?

    Yes. Integrators get environment status and maintenance notices for both UAT and production, so you know whether an issue is on your side or ours.

    What should I log on my side?

    Log the endpoint, the request body, your idempotency key, the response code, and the identifier we return.

    That set is enough to trace any record end to end without asking us to look it up.

    How do I handle a timeout on a write?

    Retry the same request with the same idempotency key. We return the original result instead of booking a second time. Never generate a fresh key for a retry.

    Can two systems share one client credential?

    You can, but we advise against it. Separate keys per system give you separate rate budgets and a clean audit trail when you need to trace which service sent a request.

    Do the REST and FIX paths produce the same records?

    Yes. Order entry over FIX and order entry over REST land in the same books and the same audit records.

    Choose the transport that fits your stack, not the one that fits a reporting need.