Autenticación

Autenticación

Toda llamada a la API lleva una API key. La key identifica una empresa dentro de tu organización y, por su prefijo, el ambiente de la DGII contra el que trabajas.

Como enviar la key

Dos formas, equivalentes. Elige una:

X-API-Key: ffs_live_ejemplodeclavenoreal000000000000000000

Authorization: Bearer ffs_live_ejemplodeclavenoreal000000000000000000
GET /api/v1/ping
curl -H "X-API-Key: ffs_test_ejemplodeclavenoreal000000000000000000" \
  https://api.fiscalflowsupport.com/api/v1/ping
import requests

r = requests.get(
    "https://api.fiscalflowsupport.com/api/v1/ping",
    headers={"X-API-Key": "ffs_test_ejemplodeclavenoreal000000000000000000"},
)
print(r.json()["data"]["environment"])
const r = await fetch("https://api.fiscalflowsupport.com/api/v1/ping", {
  headers: { "X-API-Key": "ffs_test_ejemplodeclavenoreal000000000000000000" },
});
const { data } = await r.json();
console.log(data.environment);
200 Response
{
  "success": true,
  "data": {
    "pong": true,
    "server_time": "2026-08-14T15:04:10+00:00",
    "versión": "1.0.0",
    "environment": "testecf",
    "organization": { "slug": "mi-organizacion", "name": "Mi Organización SRL" },
    "company": {
      "uuid": "9f1c2d3e-4b5a-6c7d-8e9f-0a1b2c3d4e5f",
      "rnc": "101000000",
      "legal_name": "Mi Empresa SRL"
    },
    "api_key": { "prefix": "ffs_test_abc", "name": "Integración ERP" }
  }
}

GET /api/v1/ping es la forma más rápida de confirmar que la key funciona y, sobre todo, en qué ambiente estás. Vale la pena llamarlo al arrancar tu integración y registrar el environment que devuelve.

Nunca envíes la key como parámetro de URL. Los query params quedan en los logs de servidores web, proxies e historial de navegador. Guardala en variables de entorno o en un gestor de secretos, nunca en el código fuente ni en el control de versiones.

El prefijo elige el ambiente

No hay hosts distintos por ambiente ni un parámetro que lo indique. Lo decide el prefijo de la key:

Prefijo Ambiente Para que
ffs_test_ testecf Pruebas. Desarrolla aquí. Si la empresa no tiene secuencia cargada, FiscalFlow genera un e-NCF ficticio para que puedas probar el flujo completo.
ffs_cert_ certecf Certificación ante la DGII. Los documentos se procesan de verdad pero no tienen validez fiscal.
ffs_live_ ecf Producción. Los comprobantes tienen validez fiscal y consumen números reales de la secuencia autorizada.

El ambiente que devuelve ping y el que queda grabado en cada documento (environment) salen de ese prefijo.

El ambiente de la key y el de la empresa tienen que coincidir. El prefijo de la key decide con qué ambiente se etiqueta el documento; el ambiente configurado en la empresa decide a qué servidor de la DGII se transmite. Desde 2.0.0, si no coinciden el documento se rechaza de una vez, con error_code ENVIRONMENT_MISMATCH y un mensaje que nombra los dos valores. No se firma nada y no se consume ningún e-NCF. Hasta 1.1.5 se emitía igual: una key ffs_live_ contra una empresa en testecf quedaba registrada como ecf pero había ido a pruebas. Al pasar a producción cambia las dos cosas: emite una key ffs_live_ y pon la empresa en ecf.
Una key cuyo prefijo no sea uno de los tres de arriba no autentica, la mandes por X-API-Key o por Authorization: Bearer. Hasta 1.1.5 los dos encabezados no coincidían: Bearer la rechazaba y X-API-Key la aceptaba tratándola como testecf.

Alcance de una key

Una key pertenece a una empresa, no a la organización completa. Si administras varios RNC, necesitas una key por empresa y por ambiente. Los endpoints que listan documentos filtran por la empresa de la key; unos pocos de solo lectura, como GET /api/v1/inbox y GET /api/v1/webhooks, abarcan todas las empresas de la organización.

Crear y rotar keys

Las keys se emiten desde el panel de FiscalFlow, en la pantalla Integraciones de cada empresa. La clave completa se muestra una sola vez: copiala en ese momento. Despues solo verás su prefijo.

Rotar emite una clave nueva y revoca la anterior en el acto. No hay periodo de gracia, así que despliega la clave nueva antes de rotar, o asume una ventana de fallos.

Limites de peticiones

El límite se cuenta por empresa y por minuto, según el plan:

Plan Peticiones/minuto
Empresa de pruebas (sandbox)10
Receptor30
Full Service 160
Full Service 2300

Al excederlo:

429 Response
HTTP/1.1 429 Too Many Requests
Retry-After: 37
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
Content-Type: application/json

{
  "message": "Too Many Attempts."
}

Respeta Retry-After. Ese cuerpo es el de Laravel y no lleva el sobre success/error del resto de la API: si tu cliente asume siempre la misma forma, aquí se rompe. Ver Errores y rechazos.

Lista blanca de IP

Una key puede restringirse a direcciones IP o rangos CIDR concretos, algo recomendable para producción. Una petición desde una IP no autorizada recibe 403 aunque la key sea valida:

403 Response
{
  "success": false,
  "message": "IP not whitelisted",
  "ip": "203.0.113.10"
}

Si sales por una IP dinámica, o por un balanceador con varias salidas, incluye el rango completo o deja la restricción desactivada: una IP que rota deja tu integración fuera sin aviso.

Key inválida o ausente

401 Response
{
  "success": false,
  "message": "Invalid API key"
}

Recibes lo mismo si no mandas key, si la mandaste mal, si fue revocada, o si la envías como Authorization: Bearer sin uno de los tres prefijos reconocidos. Si estás seguro de la clave, revisa que el header llegue: algunos proxies eliminan cabeceras personalizadas como X-API-Key.