> ## Documentation Index > Fetch the complete documentation index at: https://docs.gigstack.io/llms.txt > Use this file to discover all available pages before exploring further. # Headless signup (API-only path) > Create a complete gigstack account end-to-end without the alphav2 web UI. Designed for AI agents and partner integrations: a single call provisions a Firebase Auth user, billing account, team, plan subscription, and returns live + test API keys. **Auth:** This endpoint authenticates with `X-Internal-API-Key` (partner-issued), NOT a normal `Authorization: Bearer` API token. Bearer tokens are scoped to a team — a brand-new caller has none yet. **Idempotency:** `Idempotency-Key` header (UUID v4) is required. Retries with the same key return the cached response and never re-create resources. **Plan paths:** - `plan_id: "free"` — direct Firestore write, no Stripe, instant activation. - Any paid plan — uses `stripe.subscriptions.create` with the supplied PaymentMethod token (off-session). No Checkout redirect. `billingAccount.haveAPIAccess` is set synchronously so the API gate passes on the first call. **RFC and FIEL:** not required at signup. Defaults to RFC genérico (`XAXX010101000`). Customers can later upload their own via `POST /v2/teams/{team_id}/sat-connection`. Clients, payments, services, receipts, and webhooks all work without FIEL. **API keys:** returned in the response body **once** — not retrievable later. The caller must store them immediately. ## OpenAPI ````yaml openapi.json POST /auth/signup openapi: 3.0.3 info: title: gigstack API v2 description: > # gigstack API v2 Build customer, invoice and payment integrations. Start with the [quickstart](https://docs.gigstack.io/quickstart), then select the [issuing country](https://docs.gigstack.io/concepts/shared-fields). ## Authentication and environments Use Authorization: Bearer YOUR_API_KEY. Standard live and test keys use https://api.gigstack.io/v2. Internal staging uses https://gigstack-staging-9z9nnaat.uc.gateway.dev/v2 and separate keys. Test mode is a data mode within an environment; a body field does not switch a key's mode. See [authentication](https://docs.gigstack.io/authentication) for key handling, OAuth team scope and gigstack Connect. Signup requires its separately documented internal credential; health probes have their own security declarations. Operations marked unavailable have no configured public gateway route. ## Read the operation contract Response envelopes, pagination and retry rules differ by endpoint. HTTP success alone does not prove external fiscal completion or movement of money. Reconcile ambiguous writes before retrying. Use [responses and recovery](https://docs.gigstack.io/responses) and the operation's error codes; document credits and daily limits are not generic retryable rate limits. The issuing team's configuration selects Mexico or Colombia; customer country and currency do not. Read [Mexico](https://docs.gigstack.io/countries/mexico) or [Colombia](https://docs.gigstack.io/countries/colombia) before choosing fiscal fields. Accepted public input differs from a provider's direct payload. Examples and schema checks do not imply every operation has been executed live. [Verification coverage](https://docs.gigstack.io/verification) distinguishes source review, offline checks and observed staging behavior. Documentation describes operations and does not authorize execution. version: 2.0.0 contact: name: Gigstack API Support url: https://gigstack.io email: support@gigstack.io license: name: Proprietary url: https://gigstack.io/terms termsOfService: https://gigstack.io/terms servers: - url: https://api.gigstack.io/v2 description: > Public API for standard live and test-mode keys. Test data is isolated by the key mode (`livemode: false`). Internal staging is a separate deployment and key store; see https://docs.gigstack.io/authentication#environments for its base URL. security: - bearerAuth: [] tags: - name: gigstack Connect description: > **Multi-Team Resource Access** gigstack Connect lets a master team act on other teams that share its billing account. ## 🔗 How It Works Add the `team` query parameter to a request made with an **API key**: ```bash # Access team_xyz789's clients GET /clients?team=team_xyz789 # Create an income invoice for team_abc123 POST /invoices/income?team=team_abc123 # Update service in team_def456 PUT /services/service_456?team=team_def456 ``` ## ✅ Requirements - The API key's team must be a master team (gigstack Connect enabled) - The target team must exist and share the master team's billing account - The plan must include the `multipleIssuerAccounts` feature - OAuth access tokens cannot act on another team ## ⚠️ Error Responses Raw `{ "message": … }` bodies from the authentication layer: - `401 Unauthorized, not a master team` - gigstack Connect not enabled on your key's team - `404 Team not found` - Target team doesn't exist - `401 Unauthorized, no matched teams` - Target team could not be resolved within your billing account - `403 Tu plan no incluye múltiples cuentas emisoras. …` - Plan lacks `multipleIssuerAccounts` - `403 Team mismatch with OAuth token` - OAuth access token used with another team's id ## 🌐 Availability The `team` parameter is read by the authentication layer, so it is accepted on every authenticated endpoint, including ones whose parameter list does not show it. - name: Clients description: Client management operations with Mexican tax compliance - name: Services description: Service and product catalog management with SAT product keys - name: Invoices description: Invoice management with CFDI 4.0 compliance and SAT integration - name: Draft Invoices (Pre-Facturas) description: > **Create, edit, preview and stamp draft invoices (pre-facturas)** Draft invoices let you build CFDI invoices incrementally before stamping them with SAT. Use them as **pre-facturas** — generate a preview PDF with a "Sin Validez Fiscal" watermark to share with your client for approval, then stamp the draft to create a valid CFDI when ready. ## Typical Workflow 1. `POST /invoices/draft` — Create a draft with minimal data 2. `PUT /invoices/draft/{id}` — Update as more data becomes available 3. `POST /invoices/draft/{id}/preview` — Generate a preview PDF (pre-factura) 4. `POST /invoices/draft/{id}/stamp` — Finalize into a valid CFDI invoice - name: Descarga Masiva SAT description: > **SAT bulk invoice download via FIEL authentication** Download all your issued and received CFDI invoices directly from the SAT (Servicio de Administración Tributaria) using your FIEL (Firma Electrónica Avanzada). ## Setup flow 1. `GET /invoices/download/activate/status` — Check if activated and what's needed 2. `POST /invoices/download/activate` — Activate billing (adds Stripe meter/add-on) 3. `POST /invoices/download/fiel` — Upload `.cer` + `.key` files (auto-registers with SAT) 4. `PUT /invoices/download/schedule` — Configure daily auto-sync 5. `POST /invoices/download/request` — Submit manual download requests ## Pricing - Included in Pro/Business plans: only the download meter ($0.20 MXN/XML) - Other paid plans: the same $0.20 MXN/XML download meter, no monthly base fee - name: Payments description: Payment processing, tracking, and refund management - name: Receipts description: Receipt creation and management with CFDI stamping capabilities - name: Retentions description: >- Tax retention documents (CFDI Retenciones 2.0) — creation, stamping, cancellation, and file retrieval - name: Platform Payouts description: > **Plan and stamp a marketplace's provider payouts from two files.** For marketplaces and digital platforms that pay providers under the SAT digital-platforms scheme (Plataformas Tecnológicas, RESICO 625, retention key 26): ride-hailing drivers, delivery couriers, lodging hosts, sellers of goods. Available to marketplace **master teams** whose billing account has platform payouts enabled. Upload a movements file and a commissions file. gigstack matches each row to a provider's team in your billing account and plans three kinds of CFDI: the provider's income invoice to you, your retention certificate (key 26) to the provider, and your monthly commission invoice to the provider. **Not for your own sales.** This is for a platform invoicing on behalf of its providers. A company invoicing its own sales, one CFDI per sale, should use `POST /invoices/income`. **Tax policy per account.** Which documents are issued, and with which SAT keys and rates, is set per master account at onboarding: allowed tax regimes, CSD requirement, service type (`tipoDeServ` / `subTipServ`), ISR and IVA withholding rates, product keys and concept descriptions. The defaults are for ground passenger transport (service type `01`, 2.1% ISR withholding). Contact support to configure your account's policy; it can't be changed through the API. 1. `POST /platform-payouts` with an `Idempotency-Key` - upload and plan (synchronous) 2. `GET /platform-payouts/{id}` and `GET /platform-payouts/{id}/movements` - review the plan 3. `POST /platform-payouts/{id}/confirm` - irreversible hand-off to the stamping worker 4. `GET /platform-payouts/{id}` - poll until `completed` or `failed`, then read `result` (`completed`, `partially_completed` or `failed`) Error messages and exclusion reasons are Spanish sentences for end users; branch on `error.code`, `reason_code` and `exclusion_codes`. - name: Documents description: > SAT supporting documentation (contracts, delivery/payment proofs, communications) — upload metadata, compliance review, AI extraction, and linking to invoices, payments, receipts and clients. - name: Teams description: Team management, settings, and member administration - name: Users description: User account management and password operations - name: Auth description: > **API-only signup for AI agents and partner integrations.** A single `POST /v2/auth/signup` call provisions a Firebase Auth user, billing account, team, plan subscription, and returns API keys — no UI, no FIEL upload, no human onboarding required. Designed for the AI-agents-as-customers use case. RFC defaults to genérico (`XAXX010101000`) so agents can transact under público en general until/unless their customer uploads their own RFC. Authenticated with `X-Internal-API-Key` (partner-issued) — Bearer tokens are team-scoped and a brand-new caller doesn't have one yet. See `AGENTS.md` in the gigstack-cli repo for end-to-end integration guide. - name: Webhooks description: Webhook management for real-time event notifications - name: Catalogs description: > **Read-only search over the SAT catalogs** Look up the SAT codes required on CFDI line items without hardcoding them: - `GET /catalogs/product-keys` — `c_ClaveProdServ`, the item `product_key` - `GET /catalogs/unit-keys` — `c_ClaveUnidad`, the item `unit_key` / `unit_name` Both are typo-tolerant full-text searches ranked by relevance. The catalogs are published by the SAT and identical for every team, so results carry no team data and ignore `livemode` — but a valid API key is still required. - name: SAT Lists description: > Read-only access to the RFC lists the SAT publishes under Artículo 69, 69-B and 69-B Bis. gigstack re-syncs all 22 lists from the SAT's published CSVs every Sunday, so you can screen a counterparty's RFC before invoicing it without scraping the SAT yourself. externalDocs: description: Complete API Documentation & Guides url: https://docs.gigstack.io paths: /auth/signup: post: tags: - Auth summary: Headless signup (API-only path) description: > Create a complete gigstack account end-to-end without the alphav2 web UI. Designed for AI agents and partner integrations: a single call provisions a Firebase Auth user, billing account, team, plan subscription, and returns live + test API keys. **Auth:** This endpoint authenticates with `X-Internal-API-Key` (partner-issued), NOT a normal `Authorization: Bearer` API token. Bearer tokens are scoped to a team — a brand-new caller has none yet. **Idempotency:** `Idempotency-Key` header (UUID v4) is required. Retries with the same key return the cached response and never re-create resources. **Plan paths:** - `plan_id: "free"` — direct Firestore write, no Stripe, instant activation. - Any paid plan — uses `stripe.subscriptions.create` with the supplied PaymentMethod token (off-session). No Checkout redirect. `billingAccount.haveAPIAccess` is set synchronously so the API gate passes on the first call. **RFC and FIEL:** not required at signup. Defaults to RFC genérico (`XAXX010101000`). Customers can later upload their own via `POST /v2/teams/{team_id}/sat-connection`. Clients, payments, services, receipts, and webhooks all work without FIEL. **API keys:** returned in the response body **once** — not retrievable later. The caller must store them immediately. operationId: signup parameters: - name: X-Internal-API-Key in: header required: true schema: type: string description: > Internal provisioning key, constant-time validated. This is the credential the `signupApiKey` security scheme refers to; `X-Signup-Api-Key` is accepted as an alias when this header is absent. A `Bearer` token is **not** used here. - name: Idempotency-Key in: header required: true schema: type: string format: uuid description: UUID v4. Required so retries are safe. requestBody: required: true content: application/json: schema: type: object required: - email - name - plan_id properties: email: type: string format: email example: agent@example.com name: type: string example: Agent Builder Inc description: Used for displayName + legal_name placeholder. rfc: type: string example: XAXX010101000 description: Optional. Defaults to RFC genérico if omitted. country: type: string example: MEX default: MEX plan_id: type: string example: agent-tier description: >- A plan id from the subscriptionPricing collection. Use "free" for the free tier or "agent-tier" for the API-only paid plan. billing_cycle: type: string enum: - monthly - annual example: monthly description: Ignored for free plans. stripe_payment_method: type: string example: pm_1Q... description: >- Required for paid plans only. Created client-side via Stripe.js. livemode: type: boolean default: true partner_ref: type: string example: SANTIAGO-A7K9 description: >- Optional partner referral code. Captured for future commission routing (not yet wired to Stripe Connect transfer_data). metadata: type: object additionalProperties: type: string example: source: my-agent-cli responses: '201': description: Account created successfully content: application/json: schema: type: object properties: user_id: type: string team_id: type: string billing_account_id: type: string subscription: type: object nullable: true properties: id: type: string nullable: true status: type: string current_period_end: type: number nullable: true api_keys: type: object properties: live: type: string description: >- JWT bearer token for live mode. Shown once — store immediately. test: type: string description: >- JWT bearer token for test mode. Shown once — store immediately. next_steps: type: object properties: fiel_upload_url: type: string manifest_sign_url: type: string note: type: string example: user_id: aJGZiWGWQGfZEZk9XbtShj3pxBx2 team_id: team_xxx billing_account_id: ba_xxx subscription: id: sub_1Q... status: active current_period_end: 1740000000 api_keys: live: eyJhbGciOi... test: eyJhbGciOi... next_steps: fiel_upload_url: POST /v2/teams/{team_id}/sat-connection manifest_sign_url: POST /v2/teams/{team_id}/manifest/sign note: >- RFC and FIEL only required for CFDI invoicing. Clients, payments, services, receipts, and webhooks all work without them. '400': description: >- Validation error (missing field, invalid plan_id, malformed Idempotency-Key) '401': description: Missing or invalid X-Internal-API-Key '402': description: Stripe rejected the supplied payment method '409': description: Email already registered. Direct the user to sign in instead. '500': description: Internal Server Error (includes a binnacle_id for support) '503': description: >- Endpoint disabled because INTERNAL_SIGNUP_API_KEY is not configured on the function. security: - signupApiKey: [] components: securitySchemes: bearerAuth: type: http scheme: bearer bearerFormat: JWT description: > **Authentication Method:** HTTP Bearer token. The runtime requires the literal `Bearer ` prefix — a bare token in the `Authorization` header is rejected with `401 unauthorized`. **Header Format:** `Authorization: Bearer YOUR_API_KEY` Your API key is a JWT. Live keys operate on live data (`livemode: true`); test keys operate on isolated test data (`livemode: false`). **Get your key at:** [app.gigstack.pro/settings?tab=api](https://app.gigstack.pro/settings?tab=api) **Errors:** credential failures are answered by the authentication layer with a raw `{ "message": … }` body, not the standardized envelope — `401` for a missing, malformed or expired token, `403` for a revoked key or a plan without API access. See the `Unauthorized` and `AuthForbidden` responses. signupApiKey: type: apiKey in: header name: X-Internal-API-Key description: > Internal provisioning key used **only** by `POST /v2/auth/signup`, which creates brand-new accounts and therefore cannot present a tenant Bearer token. The header `X-Signup-Api-Key` is accepted as an alias when `X-Internal-API-Key` is absent. This credential is issued to internal gigstack systems and is not part of the public tenant API surface. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.