FOMDocs

Requests and errors

The base URL, response shape, error codes and rate limits.

Requests

  • Base URL: https://api.getfom.com/public/v1
  • Format: JSON in and out. Send Content-Type: application/json with a body.
  • Times are ISO 8601 in UTC, like 2026-11-25T08:00:00.000Z. Money is a whole number in the shop's currency (MMK).
  • Version: v1 only grows: new fields and endpoints may appear, so ignore fields you don't know. Breaking changes would come as /public/v2.

Responses

Every successful response has the same shape:

{
  "success": true,
  "data": { "id": "…", "order_no": "ORD-0319" },
  "meta": {
    "request_id": "req_7f3a2c",
    "timestamp": "2026-11-25T08:00:00.000Z"
  }
}

Lists add meta.pagination; see Pagination and syncing.

Errors

Errors use the same envelope with success: false:

{
  "success": false,
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "The request is not valid.",
    "details": [
      { "field": "items.0.qty", "errors": ["qty must not be less than 1"] }
    ]
  },
  "meta": { "request_id": "req_7f3a2c", "timestamp": "2026-11-25T08:00:00.000Z" }
}
StatuscodeWhat to do
401UNAUTHORIZEDThe key is wrong, revoked or expired, or its creator left the shop. Check the key.
403FORBIDDENThe key lacks a scope, its creator lacks the permission, the IP address isn't allowed, API access isn't active, or the shop is read-only. Don't retry until that changes.
404NOT_FOUNDNo such record in this shop.
409CONFLICTSomeone changed it first (expected_revision), or a request with the same Idempotency-Key is still running. Read it again, then retry.
422VALIDATION_ERRORFix the fields in details.
429TOO_MANY_REQUESTSWait Retry-After seconds, then retry.
5xxSERVER_ERRORRetry with backoff. With an Idempotency-Key, a retried write happens only once.

Quote the request_id when you ask FOM support about a request.

Rate limits

Each key can make 120 requests a minute, and each shop 600 a minute across all its keys. Every response says where you stand:

HeaderMeaning
RateLimit-LimitRequests allowed in the window
RateLimit-RemainingRequests left
RateLimit-ResetSeconds until the window resets
Retry-AfterOn a 429: seconds to wait

Syncing with updated_since and using webhooks instead of asking again and again keeps you well under the limits.

On this page