API status

There is no public status page

Faturei Hoje does not publish an availability dashboard, an incident history or an address that answers “up” or “down”. When that changes, the notice comes here.

This page is what you can do in the meantime, and it answers the question that matters at the time: is the problem mine or yours?

The call that works as a probe

GET /public/v1/me answers to any valid key and requires no specific permission. It is the cheapest call to find out whether the API is answering and whether your key is good.

• 200: the API is up and your key is valid. The problem is in the other call, not in the API.
• Anything else: use the list below.

The command is in Quickstart, in the four code languages.

Do not look for a health check address: on the API host only /public/v1 and the security.txt answer. Everything else answers 404.

Whose problem it is

The response already says which side the fix is on. What counts is the code, not the text.

It is on your side

• 401 api_key_invalid. Header, key, key state and IP list. The full checklist is in Authentication.
• 403 permission_missing, member_permission_denied, access_denied. The key’s permission and the member’s role. See Permissions.
• 403 subscription_inactive, plan_feature_unavailable, plan_limit_reached, organization_suspended. Subscription, plan or company state. The fix is in the panel.
• 404 route_not_found. Wrong path or wrong host.
• 422 validation_failed. The body carries errors, field by field.
• 429 rate_limit_exceeded. Wait out the Retry-After before repeating. See Rate limits.

It is on our side

• 500 internal_error. Keep the request_id and write to us.
• 503 service_unavailable. Try again shortly. If it persists, write to us.

It is the network in between

• No response, timeout, TLS error. The call did not reach us, or the response did not reach you. Test from another network before writing.

A 429 also shows up when one address piles up authentication failures, even with the right key. There the fix is to stop repeating the wrong call, not to wait for the API to come back.

How to tell whether it is general or only you

• Repeat from another network. Another server, your own computer, a phone off the company Wi-Fi. If it works from one place and not from another, the problem is on the path, not in the API. If the key has an IP list, the call from another network will get a 401 and that is expected: test with a key without a list, or draw conclusions only from 500 and 503.
• Repeat after a minute. 429 and 503 are temporary by nature.
• Look at View usage in the panel. If the call does not even show up there, it was never recognised as yours, and the problem is in the header, in the token or in the host.
• Count. Several calls in a row with 500 or 503, from more than one network, is our problem. A single 500 in the middle of hundreds that work is also worth an email, with the request_id.

What we do not promise here

We do not publish an availability metric, we do not announce maintenance windows and we do not promise notice of downtime. Writing any of that without the process behind it would be decoration, and decoration on a status page is worse than nothing.

What the documentation guarantees about contract changes is another matter, and that one has an automated check: see Versions and changelog.

When to write

Gather the request_id, the time with the zone, the method, the path, the status and the code, and send it to dev@fatureihoje.com. The full list is in Contact.

Next step

• Contact: what to have at hand before writing.
• Rate limits: the headers that say how much of your budget is left.
• Errors: what each code means.