Support
How to reach the Factuarea API team, what to include when reporting an issue, how API access works, the status page and the changelog.
This page is the single source of truth for how to reach the Factuarea API team and what to send so we can help you quickly.
Contact
Write from the email associated with your company in Factuarea.
What to include when reporting an issue
Every API response carries a unique request_id (in the error envelope
under error.request_id, and in the X-Request-Id response header). It is
the single most useful thing you can send us — it lets us correlate logs,
metrics and traces to investigate quickly.
{
"error": {
"type": "invalid_request_error",
"code": "parameter_invalid",
"message": "El campo client_id es obligatorio.",
"request_id": "req_01HKQS5N8VR7QXJ9K3T6BWPMZA"
}
}A good report includes:
request_idof the failing call (or several, if it's intermittent).- HTTP status and the
type/codefrom the error envelope. - Endpoint and method — e.g.
POST /v1/invoices. - Environment —
liveortest(the prefix of the key you used,fact_live_orfact_test_). Never paste the key secret itself. - What you expected vs. what happened, and the approximate timestamp.
Never share an API key secret in a support email. Send the
request_id — we can find the key and request from that alone. If a
secret has been exposed, rotate or revoke the key
from the dashboard first.
A subject line that already carries the essentials helps us triage:
422 on POST /v1/invoices — request_id req_01JBVH7K9Y4N3CDQ2EHJB1AGSVAPI access
The public API and the MCP server are included in every Factuarea plan —
there is no beta program and no separate add-on. Create your keys from
Dashboard → Developers → API Keys;
your rate-limit tier is derived from your plan (see
Rate limits). If your calls return
403 addon_not_active, your company has no active plan that includes API
access — subscribe to or renew a plan from the dashboard.
Status page
A public status page (uptime and incident history) will live at status.factuarea.com. Until then, we notify affected companies of incidents and planned maintenance directly by email to keys' registered contacts.
Changelog
Every /v1 change — new fields, new endpoints, new events, validation
fixes and deprecations — is published in the
Changelog. Breaking changes never land in
/v1; they only appear in a future /v2. See
Versioning for the stability commitment.
Self-service first
Before opening a ticket, these usually answer the question faster:
- FAQ — the most common integration questions.
- Errors — look up your
codefor the cause and fix. - Authentication — keys, scopes, rotation.
- Rate limits — quotas and back-off.