MARKY · API

Platform API v1.32.0

Referencia generada desde el contrato OpenAPI que sirve la propia API. Esta página solo describe: no envía solicitudes ni guarda credenciales.

Dirección base
https://api.marky.ec/v1
Contrato
Descargar openapi.json

Autenticación

Cada operación indica cuál de estos esquemas acepta. La credencial viaja en el encabezado Authorization.

Entrega de webhooks

Outgoing HTTPS POST: HMAC-SHA256 using complete signingSecret UTF-8 string over timestamp + "." + exact raw body. Header X-Webhook-Signature is v1=<64 lowercase hex>; X-Webhook-Timestamp is Unix seconds; X-Event-Id and X-Request-Id are UUIDv7. Reject stale timestamps (recommended 300s), compare signatures in constant time and deduplicate event_id. Delivery is at least once; 2xx succeeds, other HTTP responses retry up to 5 attempts. No redirects.

Operaciones

334 operaciones

General

GET /health health
Autenticación
Ninguna: operación pública
Respuestas
200400401403404409413500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/health'
Ver parámetros, cuerpo y esquemas de respuesta
GET /ready readiness
Autenticación
Ninguna: operación pública
Respuestas
200400401403404409413500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/ready'
Ver parámetros, cuerpo y esquemas de respuesta
GET /openapi.json openapi
Autenticación
Ninguna: operación pública
Respuestas
200400401403404409413500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/openapi.json'
Ver parámetros, cuerpo y esquemas de respuesta
GET /auth/me currentUser
Autenticación
SupabaseBearer · http bearer
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/auth/me' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/context tenantContext
Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/context' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/iam/permissions permissionCatalog

Requires users.manage in this tenant, checked again inside the write transaction.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/iam/permissions' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/iam/commands manageIam

Requires users.manage in this tenant, checked again inside the write transaction.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/iam/commands' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/api-clients listApiClients

Requires USER with current api.manage in this tenant; checks repeat in the same management transaction.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/api-clients' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/api-clients createApiClient

Requires USER with current api.manage in this tenant; checks repeat in the same management transaction.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/api-clients' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/api-clients/scopes listApiScopes

Requires USER with current api.manage in this tenant; checks repeat in the same management transaction.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/api-clients/scopes' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PATCH /tenants/{tenantId}/api-clients/{clientId}/status setApiClientStatus

Requires USER with current api.manage in this tenant; checks repeat in the same management transaction.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)clientId* (path)Idempotency-Key (header)
Respuestas
200400401403404409413429500503 
curl --request PATCH \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/api-clients/{clientId}/status' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/api-clients/{clientId}/scopes replaceApiClientScopes

Requires USER with current api.manage in this tenant; checks repeat in the same management transaction.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)clientId* (path)Idempotency-Key (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/api-clients/{clientId}/scopes' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/api-clients/{clientId}/keys listApiKeys

Requires USER with current api.manage in this tenant; checks repeat in the same management transaction.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)clientId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/api-clients/{clientId}/keys' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/api-clients/{clientId}/keys issueApiKey

Requires USER with current api.manage in this tenant; checks repeat in the same management transaction.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)clientId* (path)Idempotency-Key (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/api-clients/{clientId}/keys' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/api-clients/{clientId}/keys/{keyId}/revoke revokeApiKey

Requires USER with current api.manage in this tenant; checks repeat in the same management transaction.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)clientId* (path)keyId* (path)Idempotency-Key (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/api-clients/{clientId}/keys/{keyId}/revoke' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/context apiClientContext

Requires catalog.read. Tenant and scopes come from the verified key.

Autenticación
PlatformApiKey · http bearer
required-scopes
catalog.read
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/context' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/audit listAudit

USER with active membership and settings.manage, rechecked in the read transaction. API_CLIENT cannot read audit. Human workspace filters are combined with AND, applied before cursor pagination and tenant/warehouse access controls. Text matching is literal case-insensitive containment. productId includes all variants of the product, including archived variants; document filters never duplicate documents. Date and total bounds are inclusive.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)productId (query)
Respuestas
200400401403429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/audit' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/webhooks tenantWebhookList

Requires USER api.manage in current tenant.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/webhooks' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/webhooks tenantWebhookCreate

Requires USER api.manage in current tenant. Idempotency-Key required. Credential responses are available once; retry returns 409.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/webhooks' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
PATCH /tenants/{tenantId}/webhooks/{endpointId} tenantWebhookUpdate

Requires USER api.manage in current tenant. Idempotency-Key required; atomic effects/response/audit.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)endpointId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PATCH \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/webhooks/{endpointId}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/webhooks/{endpointId}/rotate-secret tenantWebhookRotatesecret

Requires USER api.manage in current tenant. Idempotency-Key required. Credential responses are available once; retry returns 409.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)endpointId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/webhooks/{endpointId}/rotate-secret' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/webhooks/{endpointId}/test tenantWebhookTest

Requires USER api.manage in current tenant. Idempotency-Key required; atomic effects/response/audit.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)endpointId* (path)Idempotency-Key* (header)
Respuestas
202400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/webhooks/{endpointId}/test' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/webhooks/{endpointId}/deliveries tenantWebhookDeliveries

Requires USER api.manage in current tenant.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)endpointId* (path)cursor (query)limit (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/webhooks/{endpointId}/deliveries' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/webhooks apiClientWebhookList

Requires API_CLIENT webhooks.manage, PUBLIC_API entitlement; tenant derives from key.

Autenticación
PlatformApiKey · http bearer
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/webhooks' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/webhooks apiClientWebhookCreate

Requires API_CLIENT webhooks.manage, PUBLIC_API entitlement; tenant derives from key. Idempotency-Key required. Credential responses are available once; retry returns 409.

Autenticación
PlatformApiKey · http bearer
Parámetros
Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/webhooks' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
PATCH /api-client/webhooks/{endpointId} apiClientWebhookUpdate

Requires API_CLIENT webhooks.manage, PUBLIC_API entitlement; tenant derives from key. Idempotency-Key required; atomic effects/response/audit.

Autenticación
PlatformApiKey · http bearer
Parámetros
endpointId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PATCH \
  --url 'https://api.marky.ec/v1/api-client/webhooks/{endpointId}' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/webhooks/{endpointId}/rotate-secret apiClientWebhookRotatesecret

Requires API_CLIENT webhooks.manage, PUBLIC_API entitlement; tenant derives from key. Idempotency-Key required. Credential responses are available once; retry returns 409.

Autenticación
PlatformApiKey · http bearer
Parámetros
endpointId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/webhooks/{endpointId}/rotate-secret' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/webhooks/{endpointId}/test apiClientWebhookTest

Requires API_CLIENT webhooks.manage, PUBLIC_API entitlement; tenant derives from key. Idempotency-Key required; atomic effects/response/audit.

Autenticación
PlatformApiKey · http bearer
Parámetros
endpointId* (path)Idempotency-Key* (header)
Respuestas
202400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/webhooks/{endpointId}/test' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/webhooks/{endpointId}/deliveries apiClientWebhookDeliveries

Requires API_CLIENT webhooks.manage, PUBLIC_API entitlement; tenant derives from key.

Autenticación
PlatformApiKey · http bearer
Parámetros
endpointId* (path)cursor (query)limit (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/webhooks/{endpointId}/deliveries' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/workspace Authorized workspace, legal entities and branches
Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)
Respuestas
200401403 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/workspace' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/catalog/variant-references Resolve authorized variant labels by up to 100 UUIDv7 IDs or 100 SKUs
Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)ids (query)skus (query)
Respuestas
200401403 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/variant-references' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta

Catalog

GET /tenants/{tenantId}/catalog/products tenantCatalogListProducts

Requires USER catalog.read in the requested tenant. Cursor pagination ordered by UUIDv7 ascending, max 100. Unknown query parameters rejected. Human workspace filters are combined with AND, applied before cursor pagination and tenant/warehouse access controls. Text matching is literal case-insensitive containment. productId includes all variants of the product, including archived variants; document filters never duplicate documents. Date and total bounds are inclusive.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)cursor (query)limit (query)publicationStatus (query)categoryId (query)brandId (query)manufacturerId (query)search (query)name (query)description (query)skuContains (query)barcodeContains (query)modelNumber (query)serialNumber (query)tracking (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/catalog/products tenantCatalogCreateProduct

Requires USER catalog.write in the requested tenant. Create in DRAFT; publish by PUT after an active variant exists. Type, unit and tracking become immutable once any variant exists.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/catalog/products/{productId} tenantCatalogGetProduct

Requires USER catalog.read in the requested tenant.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)productId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products/{productId}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/catalog/products/{productId} tenantCatalogUpdateProduct

Requires catalog.write. Edits article data; archived articles may update only general metadata (name, classification, descriptions and attributes). Status, archive date, publication, identifiers, type, unit, tracking and variant mode stay fixed. Forbidden archived configuration changes return ARCHIVED_PRODUCT_CONFIGURATION_LOCKED (409). Active inventory goods may switch quantity/serialized tracking only when no variant has documents, inventory or valuation references; otherwise TRACKING_HAS_TRANSACTIONS (409). Existing transaction snapshots stay intact.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)productId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products/{productId}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
DELETE /tenants/{tenantId}/catalog/products/{productId} tenantCatalogDeleteProduct

Requires catalog.write. Permanently deletes an article and its variants only when no transaction references them, including drafts and cancelled documents. Configuration media/prices and the derived search projection are removed atomically; transactional history is never deleted. ARTICLE_HAS_TRANSACTIONS returns 409. SKUs of deleted unused articles can be reused; SKUs of existing archived articles remain unique. Idempotency-Key is required and successful deletions replay safely.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)productId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request DELETE \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products/{productId}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/catalog/products/{productId}/archive tenantCatalogArchiveProduct

Requires USER catalog.write in the requested tenant. Parent becomes ARCHIVED/DRAFT; descendant records and reserved SKUs remain stored and no longer appear in storefront reads.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)productId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products/{productId}/archive' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/catalog/products/{productId}/variants tenantCatalogListVariants

Requires USER catalog.read in the requested tenant. Cursor pagination ordered by UUIDv7 ascending, max 100. Unknown query parameters rejected.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)productId* (path)cursor (query)limit (query)status (query)sku (query)barcode (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products/{productId}/variants' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/catalog/products/{productId}/variants tenantCatalogCreateVariant

Requires USER catalog.write in the requested tenant.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)productId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products/{productId}/variants' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/catalog/products/{productId}/variants/{id} tenantCatalogGetVariant

Requires USER catalog.read in the requested tenant.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)productId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products/{productId}/variants/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/catalog/products/{productId}/variants/{id} tenantCatalogUpdateVariant

Requires USER catalog.write in the requested tenant. Full replacement of editable fields; omitted optional fields reset to defaults/null. SKU and lookup codes immutable; archived records cannot be edited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)productId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products/{productId}/variants/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/catalog/products/{productId}/variants/{id}/archive tenantCatalogArchiveVariant

Requires USER catalog.write in the requested tenant. Final active variant of a published product cannot be archived; unpublish first. SKU remains reserved forever.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)productId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products/{productId}/variants/{id}/archive' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/catalog/products/{productId}/media tenantCatalogListMedia

Requires USER catalog.read in the requested tenant. Cursor pagination ordered by UUIDv7 ascending, max 100. Unknown query parameters rejected. URL metadata only; no fetch or storage provisioning. Pagination is by id; position is display metadata.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)productId* (path)cursor (query)limit (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products/{productId}/media' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/catalog/products/{productId}/media tenantCatalogCreateMedia

Requires USER catalog.write in the requested tenant. URL metadata only; no fetch or storage provisioning. Pagination is by id; position is display metadata.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)productId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products/{productId}/media' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/catalog/products/{productId}/media/{id} tenantCatalogUpdateMedia

Requires USER catalog.write in the requested tenant. Full replacement of editable fields; omitted optional fields reset to defaults/null. SKU and lookup codes immutable; archived records cannot be edited. URL metadata only; no fetch or storage provisioning. Pagination is by id; position is display metadata.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)productId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products/{productId}/media/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/catalog/products/{productId}/media/{id}/archive tenantCatalogArchiveMedia

Requires USER catalog.write in the requested tenant. URL metadata only; no fetch or storage provisioning. Pagination is by id; position is display metadata.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)productId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/products/{productId}/media/{id}/archive' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/catalog/lookups/{kind} tenantCatalogListLookups

Requires USER catalog.read in the requested tenant. Cursor pagination ordered by UUIDv7 ascending, max 100. Unknown query parameters rejected.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)kind* (path)cursor (query)limit (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/lookups/{kind}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/catalog/lookups/{kind} tenantCatalogCreateLookup

Requires USER catalog.write in the requested tenant.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)kind* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/lookups/{kind}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/catalog/lookups/{kind}/{id} tenantCatalogUpdateLookup

Requires USER catalog.write in the requested tenant. Full replacement of editable fields; omitted optional fields reset to defaults/null. SKU and lookup codes immutable; archived records cannot be edited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)kind* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/lookups/{kind}/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/catalog/lookups/{kind}/{id}/archive tenantCatalogArchiveLookup

Requires USER catalog.write in the requested tenant. Conflicts while referenced by an active product.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)kind* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/catalog/lookups/{kind}/{id}/archive' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/catalog/products apiClientCatalogListProducts

Requires API_CLIENT catalog.read and PUBLIC_API entitlement. Tenant is derived from the key. Cursor pagination ordered by UUIDv7 ascending, max 100. Unknown query parameters rejected. Products must be ACTIVE/PUBLISHED; variants/media ACTIVE under a published parent. Free attributes and internal tracking fields omitted.

Autenticación
PlatformApiKey · http bearer
Parámetros
cursor (query)limit (query)status (query)publicationStatus (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/catalog/products' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/catalog/products apiClientCatalogCreateProduct

Requires API_CLIENT catalog.write and PUBLIC_API entitlement. Tenant is derived from the key. Create in DRAFT; publish by PUT after an active variant exists. Type, unit and tracking become immutable once any variant exists.

Autenticación
PlatformApiKey · http bearer
Parámetros
Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/catalog/products' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/catalog/products/{productId} apiClientCatalogGetProduct

Requires API_CLIENT catalog.read and PUBLIC_API entitlement. Tenant is derived from the key. Products must be ACTIVE/PUBLISHED; variants/media ACTIVE under a published parent. Free attributes and internal tracking fields omitted.

Autenticación
PlatformApiKey · http bearer
Parámetros
productId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/catalog/products/{productId}' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /api-client/catalog/products/{productId} apiClientCatalogUpdateProduct

Requires catalog.write. Edits article data; archived articles may update only general metadata (name, classification, descriptions and attributes). Status, archive date, publication, identifiers, type, unit, tracking and variant mode stay fixed. Forbidden archived configuration changes return ARCHIVED_PRODUCT_CONFIGURATION_LOCKED (409). Active inventory goods may switch quantity/serialized tracking only when no variant has documents, inventory or valuation references; otherwise TRACKING_HAS_TRANSACTIONS (409). Existing transaction snapshots stay intact.

Autenticación
PlatformApiKey · http bearer
Parámetros
productId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/api-client/catalog/products/{productId}' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
DELETE /api-client/catalog/products/{productId} apiClientCatalogDeleteProduct

Requires catalog.write. Permanently deletes an article and its variants only when no transaction references them, including drafts and cancelled documents. Configuration media/prices and the derived search projection are removed atomically; transactional history is never deleted. ARTICLE_HAS_TRANSACTIONS returns 409. SKUs of deleted unused articles can be reused; SKUs of existing archived articles remain unique. Idempotency-Key is required and successful deletions replay safely.

Autenticación
PlatformApiKey · http bearer
Parámetros
productId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request DELETE \
  --url 'https://api.marky.ec/v1/api-client/catalog/products/{productId}' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/catalog/products/{productId}/archive apiClientCatalogArchiveProduct

Requires API_CLIENT catalog.write and PUBLIC_API entitlement. Tenant is derived from the key. Parent becomes ARCHIVED/DRAFT; descendant records and reserved SKUs remain stored and no longer appear in storefront reads.

Autenticación
PlatformApiKey · http bearer
Parámetros
productId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/catalog/products/{productId}/archive' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/catalog/products/{productId}/variants apiClientCatalogListVariants

Requires API_CLIENT catalog.read and PUBLIC_API entitlement. Tenant is derived from the key. Cursor pagination ordered by UUIDv7 ascending, max 100. Unknown query parameters rejected. Products must be ACTIVE/PUBLISHED; variants/media ACTIVE under a published parent. Free attributes and internal tracking fields omitted.

Autenticación
PlatformApiKey · http bearer
Parámetros
productId* (path)cursor (query)limit (query)status (query)sku (query)barcode (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/catalog/products/{productId}/variants' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/catalog/products/{productId}/variants apiClientCatalogCreateVariant

Requires API_CLIENT catalog.write and PUBLIC_API entitlement. Tenant is derived from the key.

Autenticación
PlatformApiKey · http bearer
Parámetros
productId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/catalog/products/{productId}/variants' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/catalog/products/{productId}/variants/{id} apiClientCatalogGetVariant

Requires API_CLIENT catalog.read and PUBLIC_API entitlement. Tenant is derived from the key. Products must be ACTIVE/PUBLISHED; variants/media ACTIVE under a published parent. Free attributes and internal tracking fields omitted.

Autenticación
PlatformApiKey · http bearer
Parámetros
productId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/catalog/products/{productId}/variants/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /api-client/catalog/products/{productId}/variants/{id} apiClientCatalogUpdateVariant

Requires API_CLIENT catalog.write and PUBLIC_API entitlement. Tenant is derived from the key. Full replacement of editable fields; omitted optional fields reset to defaults/null. SKU and lookup codes immutable; archived records cannot be edited.

Autenticación
PlatformApiKey · http bearer
Parámetros
productId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/api-client/catalog/products/{productId}/variants/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/catalog/products/{productId}/variants/{id}/archive apiClientCatalogArchiveVariant

Requires API_CLIENT catalog.write and PUBLIC_API entitlement. Tenant is derived from the key. Final active variant of a published product cannot be archived; unpublish first. SKU remains reserved forever.

Autenticación
PlatformApiKey · http bearer
Parámetros
productId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/catalog/products/{productId}/variants/{id}/archive' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/catalog/products/{productId}/media apiClientCatalogListMedia

Requires API_CLIENT catalog.read and PUBLIC_API entitlement. Tenant is derived from the key. Cursor pagination ordered by UUIDv7 ascending, max 100. Unknown query parameters rejected. Products must be ACTIVE/PUBLISHED; variants/media ACTIVE under a published parent. Free attributes and internal tracking fields omitted. URL metadata only; no fetch or storage provisioning. Pagination is by id; position is display metadata.

Autenticación
PlatformApiKey · http bearer
Parámetros
productId* (path)cursor (query)limit (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/catalog/products/{productId}/media' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/catalog/products/{productId}/media apiClientCatalogCreateMedia

Requires API_CLIENT catalog.write and PUBLIC_API entitlement. Tenant is derived from the key. URL metadata only; no fetch or storage provisioning. Pagination is by id; position is display metadata.

Autenticación
PlatformApiKey · http bearer
Parámetros
productId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/catalog/products/{productId}/media' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
PUT /api-client/catalog/products/{productId}/media/{id} apiClientCatalogUpdateMedia

Requires API_CLIENT catalog.write and PUBLIC_API entitlement. Tenant is derived from the key. Full replacement of editable fields; omitted optional fields reset to defaults/null. SKU and lookup codes immutable; archived records cannot be edited. URL metadata only; no fetch or storage provisioning. Pagination is by id; position is display metadata.

Autenticación
PlatformApiKey · http bearer
Parámetros
productId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/api-client/catalog/products/{productId}/media/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/catalog/products/{productId}/media/{id}/archive apiClientCatalogArchiveMedia

Requires API_CLIENT catalog.write and PUBLIC_API entitlement. Tenant is derived from the key. URL metadata only; no fetch or storage provisioning. Pagination is by id; position is display metadata.

Autenticación
PlatformApiKey · http bearer
Parámetros
productId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/catalog/products/{productId}/media/{id}/archive' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/catalog/lookups/{kind} apiClientCatalogListLookups

Requires API_CLIENT catalog.read and PUBLIC_API entitlement. Tenant is derived from the key. Cursor pagination ordered by UUIDv7 ascending, max 100. Unknown query parameters rejected. Products must be ACTIVE/PUBLISHED; variants/media ACTIVE under a published parent. Free attributes and internal tracking fields omitted.

Autenticación
PlatformApiKey · http bearer
Parámetros
kind* (path)cursor (query)limit (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/catalog/lookups/{kind}' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/catalog/lookups/{kind} apiClientCatalogCreateLookup

Requires API_CLIENT catalog.write and PUBLIC_API entitlement. Tenant is derived from the key.

Autenticación
PlatformApiKey · http bearer
Parámetros
kind* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/catalog/lookups/{kind}' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
PUT /api-client/catalog/lookups/{kind}/{id} apiClientCatalogUpdateLookup

Requires API_CLIENT catalog.write and PUBLIC_API entitlement. Tenant is derived from the key. Full replacement of editable fields; omitted optional fields reset to defaults/null. SKU and lookup codes immutable; archived records cannot be edited.

Autenticación
PlatformApiKey · http bearer
Parámetros
id* (path)kind* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/api-client/catalog/lookups/{kind}/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/catalog/lookups/{kind}/{id}/archive apiClientCatalogArchiveLookup

Requires API_CLIENT catalog.write and PUBLIC_API entitlement. Tenant is derived from the key. Conflicts while referenced by an active product.

Autenticación
PlatformApiKey · http bearer
Parámetros
id* (path)kind* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/catalog/lookups/{kind}/{id}/archive' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta

Pricing

GET /tenants/{tenantId}/pricing/price-lists tenantPricingListLists

Requires USER pricing.read, active membership and current tenant permission. Human reads include internal lists and history. Prices default ACTIVE across all periods; at filters validity. Cursor UUIDv7 ascending, default 50/max 100; unknown queries rejected.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)cursor (query)limit (query)status (query)visibility (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pricing/price-lists' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/pricing/price-lists tenantPricingCreateList

Requires USER pricing.write, active membership and current tenant permission. Full replacement of editable fields on PUT; omitted description resets null, visibility INTERNAL and date bounds unbounded. List code/currency and price variant/list/currency are immutable. ACTIVE price periods cannot overlap for the same tenant/list/variant; [from,to) intervals allow adjacent periods. Mutations require Idempotency-Key, current authorization, audit and atomic webhook outbox. Authorized pricing.write can manage internal/draft prices; response uses the credential-specific projection.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pricing/price-lists' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/pricing/price-lists/{listId} tenantPricingGetList

Requires USER pricing.read, active membership and current tenant permission. Human reads include internal lists and history. Prices default ACTIVE across all periods; at filters validity. Cursor UUIDv7 ascending, default 50/max 100; unknown queries rejected.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)listId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pricing/price-lists/{listId}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/pricing/price-lists/{listId} tenantPricingUpdateList

Requires USER pricing.write, active membership and current tenant permission. Full replacement of editable fields on PUT; omitted description resets null, visibility INTERNAL and date bounds unbounded. List code/currency and price variant/list/currency are immutable. ACTIVE price periods cannot overlap for the same tenant/list/variant; [from,to) intervals allow adjacent periods. Mutations require Idempotency-Key, current authorization, audit and atomic webhook outbox. Authorized pricing.write can manage internal/draft prices; response uses the credential-specific projection.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)listId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pricing/price-lists/{listId}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/pricing/price-lists/{listId}/archive tenantPricingArchiveList

Requires USER pricing.write, active membership and current tenant permission. Archive is permanent; descendants/history retained and list code reserved. Full replacement of editable fields on PUT; omitted description resets null, visibility INTERNAL and date bounds unbounded. List code/currency and price variant/list/currency are immutable. ACTIVE price periods cannot overlap for the same tenant/list/variant; [from,to) intervals allow adjacent periods. Mutations require Idempotency-Key, current authorization, audit and atomic webhook outbox. Authorized pricing.write can manage internal/draft prices; response uses the credential-specific projection.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)listId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pricing/price-lists/{listId}/archive' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/pricing/price-lists/{listId}/prices tenantPricingListPrices

Requires USER pricing.read, active membership and current tenant permission. Human reads include internal lists and history. Prices default ACTIVE across all periods; at filters validity. variantIds reads the prices of up to 100 variants of this company in one request and cannot be combined with variantId; ids of other companies match nothing. Cursor UUIDv7 ascending, default 50/max 100; unknown queries rejected.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)listId* (path)cursor (query)limit (query)status (query)variantId (query)variantIds (query)at (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pricing/price-lists/{listId}/prices' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/pricing/price-lists/{listId}/prices tenantPricingCreatePrice

Requires USER pricing.write, active membership and current tenant permission. Full replacement of editable fields on PUT; omitted description resets null, visibility INTERNAL and date bounds unbounded. List code/currency and price variant/list/currency are immutable. ACTIVE price periods cannot overlap for the same tenant/list/variant; [from,to) intervals allow adjacent periods. Mutations require Idempotency-Key, current authorization, audit and atomic webhook outbox. Authorized pricing.write can manage internal/draft prices; response uses the credential-specific projection.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)listId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pricing/price-lists/{listId}/prices' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/pricing/price-lists/{listId}/prices/{id} tenantPricingGetPrice

Requires USER pricing.read, active membership and current tenant permission. Human reads include internal lists and history. Prices default ACTIVE across all periods; at filters validity. Cursor UUIDv7 ascending, default 50/max 100; unknown queries rejected.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)listId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pricing/price-lists/{listId}/prices/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/pricing/price-lists/{listId}/prices/{id} tenantPricingUpdatePrice

Requires USER pricing.write, active membership and current tenant permission. Full replacement of editable fields on PUT; omitted description resets null, visibility INTERNAL and date bounds unbounded. List code/currency and price variant/list/currency are immutable. ACTIVE price periods cannot overlap for the same tenant/list/variant; [from,to) intervals allow adjacent periods. Mutations require Idempotency-Key, current authorization, audit and atomic webhook outbox. Authorized pricing.write can manage internal/draft prices; response uses the credential-specific projection.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)listId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pricing/price-lists/{listId}/prices/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/pricing/price-lists/{listId}/prices/{id}/archive tenantPricingArchivePrice

Requires USER pricing.write, active membership and current tenant permission. Archived price cannot be restored or edited; frees its active validity interval. Full replacement of editable fields on PUT; omitted description resets null, visibility INTERNAL and date bounds unbounded. List code/currency and price variant/list/currency are immutable. ACTIVE price periods cannot overlap for the same tenant/list/variant; [from,to) intervals allow adjacent periods. Mutations require Idempotency-Key, current authorization, audit and atomic webhook outbox. Authorized pricing.write can manage internal/draft prices; response uses the credential-specific projection.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)listId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pricing/price-lists/{listId}/prices/{id}/archive' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/pricing/price-lists/{listId}/resolve/{variantId} tenantPricingResolvePrice

Requires USER pricing.read, active membership and current tenant permission. Resolve exactly one ACTIVE price at the database statement time (optional UTC at for humans only). Missing effective price returns 404; no fallback list, discount, tax, conversion or rounding. Human reads include internal lists and history. Prices default ACTIVE across all periods; at filters validity. Cursor UUIDv7 ascending, default 50/max 100; unknown queries rejected.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)listId* (path)variantId* (path)at (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pricing/price-lists/{listId}/resolve/{variantId}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/pricing/price-lists apiClientPricingListLists

Requires API_CLIENT pricing.read and PUBLIC_API entitlement; tenant is derived from the verified key. API-key reads expose ACTIVE/PUBLIC lists and ACTIVE currently effective prices for ACTIVE variants under ACTIVE/PUBLISHED products. Internal description and tenant/archive fields omitted; historical at and ARCHIVED/INTERNAL filters rejected.

Autenticación
PlatformApiKey · http bearer
required-scopes
pricing.read
Parámetros
cursor (query)limit (query)status (query)visibility (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/pricing/price-lists' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/pricing/price-lists apiClientPricingCreateList

Requires API_CLIENT pricing.write and PUBLIC_API entitlement; tenant is derived from the verified key. Full replacement of editable fields on PUT; omitted description resets null, visibility INTERNAL and date bounds unbounded. List code/currency and price variant/list/currency are immutable. ACTIVE price periods cannot overlap for the same tenant/list/variant; [from,to) intervals allow adjacent periods. Mutations require Idempotency-Key, current authorization, audit and atomic webhook outbox. Authorized pricing.write can manage internal/draft prices; response uses the credential-specific projection.

Autenticación
PlatformApiKey · http bearer
required-scopes
pricing.write
Parámetros
Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/pricing/price-lists' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/pricing/price-lists/{listId} apiClientPricingGetList

Requires API_CLIENT pricing.read and PUBLIC_API entitlement; tenant is derived from the verified key. API-key reads expose ACTIVE/PUBLIC lists and ACTIVE currently effective prices for ACTIVE variants under ACTIVE/PUBLISHED products. Internal description and tenant/archive fields omitted; historical at and ARCHIVED/INTERNAL filters rejected.

Autenticación
PlatformApiKey · http bearer
required-scopes
pricing.read
Parámetros
listId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/pricing/price-lists/{listId}' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /api-client/pricing/price-lists/{listId} apiClientPricingUpdateList

Requires API_CLIENT pricing.write and PUBLIC_API entitlement; tenant is derived from the verified key. Full replacement of editable fields on PUT; omitted description resets null, visibility INTERNAL and date bounds unbounded. List code/currency and price variant/list/currency are immutable. ACTIVE price periods cannot overlap for the same tenant/list/variant; [from,to) intervals allow adjacent periods. Mutations require Idempotency-Key, current authorization, audit and atomic webhook outbox. Authorized pricing.write can manage internal/draft prices; response uses the credential-specific projection.

Autenticación
PlatformApiKey · http bearer
required-scopes
pricing.write
Parámetros
listId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/api-client/pricing/price-lists/{listId}' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/pricing/price-lists/{listId}/archive apiClientPricingArchiveList

Requires API_CLIENT pricing.write and PUBLIC_API entitlement; tenant is derived from the verified key. Archive is permanent; descendants/history retained and list code reserved. Full replacement of editable fields on PUT; omitted description resets null, visibility INTERNAL and date bounds unbounded. List code/currency and price variant/list/currency are immutable. ACTIVE price periods cannot overlap for the same tenant/list/variant; [from,to) intervals allow adjacent periods. Mutations require Idempotency-Key, current authorization, audit and atomic webhook outbox. Authorized pricing.write can manage internal/draft prices; response uses the credential-specific projection.

Autenticación
PlatformApiKey · http bearer
required-scopes
pricing.write
Parámetros
listId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/pricing/price-lists/{listId}/archive' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/pricing/price-lists/{listId}/prices apiClientPricingListPrices

Requires API_CLIENT pricing.read and PUBLIC_API entitlement; tenant is derived from the verified key. API-key reads expose ACTIVE/PUBLIC lists and ACTIVE currently effective prices for ACTIVE variants under ACTIVE/PUBLISHED products. Internal description and tenant/archive fields omitted; historical at and ARCHIVED/INTERNAL filters rejected.

Autenticación
PlatformApiKey · http bearer
required-scopes
pricing.read
Parámetros
listId* (path)cursor (query)limit (query)status (query)variantId (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/pricing/price-lists/{listId}/prices' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/pricing/price-lists/{listId}/prices apiClientPricingCreatePrice

Requires API_CLIENT pricing.write and PUBLIC_API entitlement; tenant is derived from the verified key. Full replacement of editable fields on PUT; omitted description resets null, visibility INTERNAL and date bounds unbounded. List code/currency and price variant/list/currency are immutable. ACTIVE price periods cannot overlap for the same tenant/list/variant; [from,to) intervals allow adjacent periods. Mutations require Idempotency-Key, current authorization, audit and atomic webhook outbox. Authorized pricing.write can manage internal/draft prices; response uses the credential-specific projection.

Autenticación
PlatformApiKey · http bearer
required-scopes
pricing.write
Parámetros
listId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/pricing/price-lists/{listId}/prices' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/pricing/price-lists/{listId}/prices/{id} apiClientPricingGetPrice

Requires API_CLIENT pricing.read and PUBLIC_API entitlement; tenant is derived from the verified key. API-key reads expose ACTIVE/PUBLIC lists and ACTIVE currently effective prices for ACTIVE variants under ACTIVE/PUBLISHED products. Internal description and tenant/archive fields omitted; historical at and ARCHIVED/INTERNAL filters rejected.

Autenticación
PlatformApiKey · http bearer
required-scopes
pricing.read
Parámetros
listId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/pricing/price-lists/{listId}/prices/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /api-client/pricing/price-lists/{listId}/prices/{id} apiClientPricingUpdatePrice

Requires API_CLIENT pricing.write and PUBLIC_API entitlement; tenant is derived from the verified key. Full replacement of editable fields on PUT; omitted description resets null, visibility INTERNAL and date bounds unbounded. List code/currency and price variant/list/currency are immutable. ACTIVE price periods cannot overlap for the same tenant/list/variant; [from,to) intervals allow adjacent periods. Mutations require Idempotency-Key, current authorization, audit and atomic webhook outbox. Authorized pricing.write can manage internal/draft prices; response uses the credential-specific projection.

Autenticación
PlatformApiKey · http bearer
required-scopes
pricing.write
Parámetros
listId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/api-client/pricing/price-lists/{listId}/prices/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/pricing/price-lists/{listId}/prices/{id}/archive apiClientPricingArchivePrice

Requires API_CLIENT pricing.write and PUBLIC_API entitlement; tenant is derived from the verified key. Archived price cannot be restored or edited; frees its active validity interval. Full replacement of editable fields on PUT; omitted description resets null, visibility INTERNAL and date bounds unbounded. List code/currency and price variant/list/currency are immutable. ACTIVE price periods cannot overlap for the same tenant/list/variant; [from,to) intervals allow adjacent periods. Mutations require Idempotency-Key, current authorization, audit and atomic webhook outbox. Authorized pricing.write can manage internal/draft prices; response uses the credential-specific projection.

Autenticación
PlatformApiKey · http bearer
required-scopes
pricing.write
Parámetros
listId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/pricing/price-lists/{listId}/prices/{id}/archive' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/pricing/price-lists/{listId}/resolve/{variantId} apiClientPricingResolvePrice

Requires API_CLIENT pricing.read and PUBLIC_API entitlement; tenant is derived from the verified key. Resolve exactly one ACTIVE price at the database statement time (optional UTC at for humans only). Missing effective price returns 404; no fallback list, discount, tax, conversion or rounding. API-key reads expose ACTIVE/PUBLIC lists and ACTIVE currently effective prices for ACTIVE variants under ACTIVE/PUBLISHED products. Internal description and tenant/archive fields omitted; historical at and ARCHIVED/INTERNAL filters rejected.

Autenticación
PlatformApiKey · http bearer
required-scopes
pricing.read
Parámetros
listId* (path)variantId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/pricing/price-lists/{listId}/resolve/{variantId}' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta

Inventory

GET /tenants/{tenantId}/inventory/warehouses tenantInventoryListWarehouses

Requires USER inventory.read, active membership/current tenant permission. Cursor UUIDv7 ascending, default50/max100, unknown query rejected. Stock cursor is variantId within warehouse; others resource id.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.read
Parámetros
tenantId* (path)cursor (query)limit (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/warehouses tenantInventoryCreateWarehouse

Requires USER inventory.adjust, active membership/current tenant permission. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.adjust
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/warehouses/{warehouseId} tenantInventoryGetWarehouse

Requires USER inventory.read, active membership/current tenant permission.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.read
Parámetros
tenantId* (path)warehouseId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses/{warehouseId}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/inventory/warehouses/{warehouseId} tenantInventoryUpdateWarehouse

Requires USER inventory.adjust, active membership/current tenant permission. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.Full replacement; only name changes, send unchanged identity fields.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.adjust
Parámetros
tenantId* (path)warehouseId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses/{warehouseId}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/warehouses/{warehouseId}/archive tenantInventoryArchiveWarehouse

Requires USER inventory.adjust, active membership/current tenant permission. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.adjust
Parámetros
tenantId* (path)warehouseId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses/{warehouseId}/archive' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/warehouses/{warehouseId}/locations tenantInventoryListLocations

Requires USER inventory.read, active membership/current tenant permission. Cursor UUIDv7 ascending, default50/max100, unknown query rejected. Stock cursor is variantId within warehouse; others resource id.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.read
Parámetros
tenantId* (path)warehouseId* (path)cursor (query)limit (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses/{warehouseId}/locations' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/warehouses/{warehouseId}/locations tenantInventoryCreateLocation

Requires USER inventory.adjust, active membership/current tenant permission. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.adjust
Parámetros
tenantId* (path)warehouseId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses/{warehouseId}/locations' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/warehouses/{warehouseId}/locations/{id} tenantInventoryGetLocation

Requires USER inventory.read, active membership/current tenant permission.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.read
Parámetros
tenantId* (path)warehouseId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses/{warehouseId}/locations/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/inventory/warehouses/{warehouseId}/locations/{id} tenantInventoryUpdateLocation

Requires USER inventory.adjust, active membership/current tenant permission. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.Full replacement; only name changes, send unchanged identity fields.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.adjust
Parámetros
tenantId* (path)warehouseId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses/{warehouseId}/locations/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/warehouses/{warehouseId}/locations/{id}/archive tenantInventoryArchiveLocation

Requires USER inventory.adjust, active membership/current tenant permission. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.adjust
Parámetros
tenantId* (path)warehouseId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses/{warehouseId}/locations/{id}/archive' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/warehouses/{warehouseId}/stock tenantInventoryListStock

Requires USER inventory.read, active membership/current tenant permission. Cursor UUIDv7 ascending, default50/max100, unknown query rejected. Stock cursor is variantId within warehouse; others resource id.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.read
Parámetros
tenantId* (path)warehouseId* (path)cursor (query)limit (query)variantId (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses/{warehouseId}/stock' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/warehouses/{warehouseId}/stock/{variantId} tenantInventoryGetStock

Requires USER inventory.read, active membership/current tenant permission.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.read
Parámetros
tenantId* (path)warehouseId* (path)variantId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses/{warehouseId}/stock/{variantId}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/warehouses/{warehouseId}/stock/{variantId}/reconciliation tenantInventoryReconcileStock

Requires USER inventory.read, active membership/current tenant permission. Read-only comparison against both immutable ledgers, using one SQL snapshot.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.read
Parámetros
tenantId* (path)warehouseId* (path)variantId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses/{warehouseId}/stock/{variantId}/reconciliation' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/movements tenantInventoryListMovements

Requires USER inventory.read, active membership/current tenant permission. Cursor UUIDv7 ascending, default50/max100, unknown query rejected. Stock cursor is variantId within warehouse; others resource id. Human workspace filters are combined with AND, applied before cursor pagination and tenant/warehouse access controls. Text matching is literal case-insensitive containment. productId includes all variants of the product, including archived variants; document filters never duplicate documents. Date and total bounds are inclusive.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.read
Parámetros
tenantId* (path)cursor (query)limit (query)variantId (query)warehouseId (query)movementType (query)productId (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/movements' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/movements/{id} tenantInventoryGetMovement

Requires USER inventory.read, active membership/current tenant permission.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.read
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/movements/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/adjustments tenantInventoryCreateAdjustment

Requires USER inventory.adjust, active membership/current tenant permission. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.adjust
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/adjustments' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/transfers tenantInventoryCreateTransfer

Requires USER inventory.transfer, active membership/current tenant permission. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.transfer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/transfers' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/reservations tenantInventoryListReservations

Requires USER inventory.read, active membership/current tenant permission. Cursor UUIDv7 ascending, default50/max100, unknown query rejected. Stock cursor is variantId within warehouse; others resource id.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.read
Parámetros
tenantId* (path)cursor (query)limit (query)variantId (query)warehouseId (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/reservations' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/reservations tenantInventoryCreateReservation

Requires USER inventory.adjust, active membership/current tenant permission. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.adjust
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/reservations' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/reservations/{id} tenantInventoryGetReservation

Requires USER inventory.read, active membership/current tenant permission.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.read
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/reservations/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/reservations/{id}/release tenantInventoryReleaseReservation

Requires USER inventory.adjust, active membership/current tenant permission. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.Release the entire quantity or serialized unit reservation once; unit release projects AVAILABLE with a new version. No automatic expiry or consumption.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.adjust
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/reservations/{id}/release' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/inventory/adjustments apiClientInventoryCreateAdjustment

Requires API_CLIENT inventory.write and PUBLIC_API, tenant derived from key. Safe availability or write receipt omits locations, reason, reference and actor; no warehouse/stock/history read endpoints for API clients. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.

Autenticación
PlatformApiKey · http bearer
required-scopes
inventory.write
Parámetros
Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/inventory/adjustments' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/inventory/transfers apiClientInventoryCreateTransfer

Requires API_CLIENT inventory.write and PUBLIC_API, tenant derived from key. Safe availability or write receipt omits locations, reason, reference and actor; no warehouse/stock/history read endpoints for API clients. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.

Autenticación
PlatformApiKey · http bearer
required-scopes
inventory.write
Parámetros
Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/inventory/transfers' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/inventory/reservations apiClientInventoryCreateReservation

Requires API_CLIENT inventory.write and PUBLIC_API, tenant derived from key. Safe availability or write receipt omits locations, reason, reference and actor; no warehouse/stock/history read endpoints for API clients. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.

Autenticación
PlatformApiKey · http bearer
required-scopes
inventory.write
Parámetros
Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/inventory/reservations' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/inventory/reservations/{id}/release apiClientInventoryReleaseReservation

Requires API_CLIENT inventory.write and PUBLIC_API, tenant derived from key. Safe availability or write receipt omits locations, reason, reference and actor; no warehouse/stock/history read endpoints for API clients. Requires Idempotency-Key, fresh authorization before replay; ledger/reservation events, stock projection, response, audit and outbox commit atomically. Quantity cannot overdraw onHand-reserved. Warehouse/location identity and archived records are immutable; warehouse archive requires zero onHand/reserved and no serialized units in custody. Quantity adjustments/transfers use nonserialized products; units have dedicated INV-2 routes. Business purchase/sale types and direct stock assignment are unavailable.Release the entire quantity or serialized unit reservation once; unit release projects AVAILABLE with a new version. No automatic expiry or consumption.

Autenticación
PlatformApiKey · http bearer
required-scopes
inventory.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/inventory/reservations/{id}/release' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/inventory/availability/{variantId} apiClientInventoryGetAvailability

Requires API_CLIENT inventory.read and PUBLIC_API, tenant derived from key. Safe availability or write receipt omits locations, reason, reference and actor; no warehouse/stock/history read endpoints for API clients.

Autenticación
PlatformApiKey · http bearer
required-scopes
inventory.read
Parámetros
variantId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/inventory/availability/{variantId}' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/transfer-orders tenantInventoryGetTransferOrders

Human Supabase USER only; permissions inventory.read. Transfer orders move goods between two warehouses of one legal entity through an IN_TRANSIT warehouse of that entity. Approval moves nothing. Dispatch ships the whole order from the origin into transit using the inventory ledger, so goods are never available in two places; serialized lines name the exact units and every unit keeps its identity. Receipts resolve goods in transit as RECEIVED at the destination, LOST, or RETURNED to the origin; unresolved goods stay in transit and the order stays PARTIALLY_RECEIVED. Cancellation is possible only before dispatch and never restores stock. Goods held in transit by an order cannot leave through manual movements. No partial dispatch, costs, valuation or transfers across legal entities. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)warehouseId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/transfer-orders' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/transfer-orders tenantInventoryPostTransferOrders

Human Supabase USER only; permissions inventory.transfer. Transfer orders move goods between two warehouses of one legal entity through an IN_TRANSIT warehouse of that entity. Approval moves nothing. Dispatch ships the whole order from the origin into transit using the inventory ledger, so goods are never available in two places; serialized lines name the exact units and every unit keeps its identity. Receipts resolve goods in transit as RECEIVED at the destination, LOST, or RETURNED to the origin; unresolved goods stay in transit and the order stays PARTIALLY_RECEIVED. Cancellation is possible only before dispatch and never restores stock. Goods held in transit by an order cannot leave through manual movements. No partial dispatch, costs, valuation or transfers across legal entities. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/transfer-orders' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/transfer-orders/{id} tenantInventoryGetTransferOrdersById

Human Supabase USER only; permissions inventory.read. Transfer orders move goods between two warehouses of one legal entity through an IN_TRANSIT warehouse of that entity. Approval moves nothing. Dispatch ships the whole order from the origin into transit using the inventory ledger, so goods are never available in two places; serialized lines name the exact units and every unit keeps its identity. Receipts resolve goods in transit as RECEIVED at the destination, LOST, or RETURNED to the origin; unresolved goods stay in transit and the order stays PARTIALLY_RECEIVED. Cancellation is possible only before dispatch and never restores stock. Goods held in transit by an order cannot leave through manual movements. No partial dispatch, costs, valuation or transfers across legal entities. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/transfer-orders/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/inventory/transfer-orders/{id} tenantInventoryPutTransferOrdersById

Human Supabase USER only; permissions inventory.transfer. Transfer orders move goods between two warehouses of one legal entity through an IN_TRANSIT warehouse of that entity. Approval moves nothing. Dispatch ships the whole order from the origin into transit using the inventory ledger, so goods are never available in two places; serialized lines name the exact units and every unit keeps its identity. Receipts resolve goods in transit as RECEIVED at the destination, LOST, or RETURNED to the origin; unresolved goods stay in transit and the order stays PARTIALLY_RECEIVED. Cancellation is possible only before dispatch and never restores stock. Goods held in transit by an order cannot leave through manual movements. No partial dispatch, costs, valuation or transfers across legal entities. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/transfer-orders/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/transfer-orders/{id}/approve tenantInventoryPostTransferOrdersByIdApprove

Human Supabase USER only; permissions inventory.transfer, inventory.adjust. Transfer orders move goods between two warehouses of one legal entity through an IN_TRANSIT warehouse of that entity. Approval moves nothing. Dispatch ships the whole order from the origin into transit using the inventory ledger, so goods are never available in two places; serialized lines name the exact units and every unit keeps its identity. Receipts resolve goods in transit as RECEIVED at the destination, LOST, or RETURNED to the origin; unresolved goods stay in transit and the order stays PARTIALLY_RECEIVED. Cancellation is possible only before dispatch and never restores stock. Goods held in transit by an order cannot leave through manual movements. No partial dispatch, costs, valuation or transfers across legal entities. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/transfer-orders/{id}/approve' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/transfer-orders/{id}/cancel tenantInventoryPostTransferOrdersByIdCancel

Human Supabase USER only; permissions inventory.transfer. Transfer orders move goods between two warehouses of one legal entity through an IN_TRANSIT warehouse of that entity. Approval moves nothing. Dispatch ships the whole order from the origin into transit using the inventory ledger, so goods are never available in two places; serialized lines name the exact units and every unit keeps its identity. Receipts resolve goods in transit as RECEIVED at the destination, LOST, or RETURNED to the origin; unresolved goods stay in transit and the order stays PARTIALLY_RECEIVED. Cancellation is possible only before dispatch and never restores stock. Goods held in transit by an order cannot leave through manual movements. No partial dispatch, costs, valuation or transfers across legal entities. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/transfer-orders/{id}/cancel' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/transfer-orders/{id}/dispatch tenantInventoryPostTransferOrdersByIdDispatch

Human Supabase USER only; permissions inventory.transfer. Transfer orders move goods between two warehouses of one legal entity through an IN_TRANSIT warehouse of that entity. Approval moves nothing. Dispatch ships the whole order from the origin into transit using the inventory ledger, so goods are never available in two places; serialized lines name the exact units and every unit keeps its identity. Receipts resolve goods in transit as RECEIVED at the destination, LOST, or RETURNED to the origin; unresolved goods stay in transit and the order stays PARTIALLY_RECEIVED. Cancellation is possible only before dispatch and never restores stock. Goods held in transit by an order cannot leave through manual movements. No partial dispatch, costs, valuation or transfers across legal entities. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/transfer-orders/{id}/dispatch' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/transfer-orders/{id}/receipts tenantInventoryPostTransferOrdersByIdReceipts

Human Supabase USER only; permissions inventory.transfer; inventory.adjust as well when a line is LOST. Transfer orders move goods between two warehouses of one legal entity through an IN_TRANSIT warehouse of that entity. Approval moves nothing. Dispatch ships the whole order from the origin into transit using the inventory ledger, so goods are never available in two places; serialized lines name the exact units and every unit keeps its identity. Receipts resolve goods in transit as RECEIVED at the destination, LOST, or RETURNED to the origin; unresolved goods stay in transit and the order stays PARTIALLY_RECEIVED. Cancellation is possible only before dispatch and never restores stock. Goods held in transit by an order cannot leave through manual movements. No partial dispatch, costs, valuation or transfers across legal entities. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/transfer-orders/{id}/receipts' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/import-orders tenantInventoryGetImportOrders

Human Supabase USER only; permissions inventory.read. Import orders move goods between two legal entities of the same tenant; the existing transfer still refuses to cross entities. The order states who owns the goods in transit: the transit warehouse belongs to that entity. Exactly one ledger movement (INTERCOMPANY) crosses entities, at receipt when the origin owns the transit and at dispatch when the destination does; a return to the origin crosses back in the second case. Approval moves nothing; dispatch ships the whole order; receipts resolve goods as RECEIVED, LOST or RETURNED and the rest stays in transit; cancellation is possible only before dispatch. Serialized units keep their identifier, serial and IMEI and change legal entity with that single movement: they are never registered again. Declared values and the export/import document references are statements kept on the order; no costs, customs duties, taxes, FX or commercial invoices between entities are created. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)legalEntityId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/import-orders' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/import-orders tenantInventoryPostImportOrders

Human Supabase USER only; permissions inventory.transfer. Import orders move goods between two legal entities of the same tenant; the existing transfer still refuses to cross entities. The order states who owns the goods in transit: the transit warehouse belongs to that entity. Exactly one ledger movement (INTERCOMPANY) crosses entities, at receipt when the origin owns the transit and at dispatch when the destination does; a return to the origin crosses back in the second case. Approval moves nothing; dispatch ships the whole order; receipts resolve goods as RECEIVED, LOST or RETURNED and the rest stays in transit; cancellation is possible only before dispatch. Serialized units keep their identifier, serial and IMEI and change legal entity with that single movement: they are never registered again. Declared values and the export/import document references are statements kept on the order; no costs, customs duties, taxes, FX or commercial invoices between entities are created. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/import-orders' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/import-orders/{id} tenantInventoryGetImportOrdersById

Human Supabase USER only; permissions inventory.read. Import orders move goods between two legal entities of the same tenant; the existing transfer still refuses to cross entities. The order states who owns the goods in transit: the transit warehouse belongs to that entity. Exactly one ledger movement (INTERCOMPANY) crosses entities, at receipt when the origin owns the transit and at dispatch when the destination does; a return to the origin crosses back in the second case. Approval moves nothing; dispatch ships the whole order; receipts resolve goods as RECEIVED, LOST or RETURNED and the rest stays in transit; cancellation is possible only before dispatch. Serialized units keep their identifier, serial and IMEI and change legal entity with that single movement: they are never registered again. Declared values and the export/import document references are statements kept on the order; no costs, customs duties, taxes, FX or commercial invoices between entities are created. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/import-orders/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/inventory/import-orders/{id} tenantInventoryPutImportOrdersById

Human Supabase USER only; permissions inventory.transfer. Import orders move goods between two legal entities of the same tenant; the existing transfer still refuses to cross entities. The order states who owns the goods in transit: the transit warehouse belongs to that entity. Exactly one ledger movement (INTERCOMPANY) crosses entities, at receipt when the origin owns the transit and at dispatch when the destination does; a return to the origin crosses back in the second case. Approval moves nothing; dispatch ships the whole order; receipts resolve goods as RECEIVED, LOST or RETURNED and the rest stays in transit; cancellation is possible only before dispatch. Serialized units keep their identifier, serial and IMEI and change legal entity with that single movement: they are never registered again. Declared values and the export/import document references are statements kept on the order; no costs, customs duties, taxes, FX or commercial invoices between entities are created. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/import-orders/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/import-orders/{id}/approve tenantInventoryPostImportOrdersByIdApprove

Human Supabase USER only; permissions inventory.transfer, inventory.adjust. Import orders move goods between two legal entities of the same tenant; the existing transfer still refuses to cross entities. The order states who owns the goods in transit: the transit warehouse belongs to that entity. Exactly one ledger movement (INTERCOMPANY) crosses entities, at receipt when the origin owns the transit and at dispatch when the destination does; a return to the origin crosses back in the second case. Approval moves nothing; dispatch ships the whole order; receipts resolve goods as RECEIVED, LOST or RETURNED and the rest stays in transit; cancellation is possible only before dispatch. Serialized units keep their identifier, serial and IMEI and change legal entity with that single movement: they are never registered again. Declared values and the export/import document references are statements kept on the order; no costs, customs duties, taxes, FX or commercial invoices between entities are created. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/import-orders/{id}/approve' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/import-orders/{id}/cancel tenantInventoryPostImportOrdersByIdCancel

Human Supabase USER only; permissions inventory.transfer. Import orders move goods between two legal entities of the same tenant; the existing transfer still refuses to cross entities. The order states who owns the goods in transit: the transit warehouse belongs to that entity. Exactly one ledger movement (INTERCOMPANY) crosses entities, at receipt when the origin owns the transit and at dispatch when the destination does; a return to the origin crosses back in the second case. Approval moves nothing; dispatch ships the whole order; receipts resolve goods as RECEIVED, LOST or RETURNED and the rest stays in transit; cancellation is possible only before dispatch. Serialized units keep their identifier, serial and IMEI and change legal entity with that single movement: they are never registered again. Declared values and the export/import document references are statements kept on the order; no costs, customs duties, taxes, FX or commercial invoices between entities are created. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/import-orders/{id}/cancel' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/import-orders/{id}/dispatch tenantInventoryPostImportOrdersByIdDispatch

Human Supabase USER only; permissions inventory.transfer. Import orders move goods between two legal entities of the same tenant; the existing transfer still refuses to cross entities. The order states who owns the goods in transit: the transit warehouse belongs to that entity. Exactly one ledger movement (INTERCOMPANY) crosses entities, at receipt when the origin owns the transit and at dispatch when the destination does; a return to the origin crosses back in the second case. Approval moves nothing; dispatch ships the whole order; receipts resolve goods as RECEIVED, LOST or RETURNED and the rest stays in transit; cancellation is possible only before dispatch. Serialized units keep their identifier, serial and IMEI and change legal entity with that single movement: they are never registered again. Declared values and the export/import document references are statements kept on the order; no costs, customs duties, taxes, FX or commercial invoices between entities are created. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/import-orders/{id}/dispatch' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/import-orders/{id}/receipts tenantInventoryPostImportOrdersByIdReceipts

Human Supabase USER only; permissions inventory.transfer; inventory.adjust as well when a line is LOST. Import orders move goods between two legal entities of the same tenant; the existing transfer still refuses to cross entities. The order states who owns the goods in transit: the transit warehouse belongs to that entity. Exactly one ledger movement (INTERCOMPANY) crosses entities, at receipt when the origin owns the transit and at dispatch when the destination does; a return to the origin crosses back in the second case. Approval moves nothing; dispatch ships the whole order; receipts resolve goods as RECEIVED, LOST or RETURNED and the rest stays in transit; cancellation is possible only before dispatch. Serialized units keep their identifier, serial and IMEI and change legal entity with that single movement: they are never registered again. Declared values and the export/import document references are statements kept on the order; no costs, customs duties, taxes, FX or commercial invoices between entities are created. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/import-orders/{id}/receipts' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/units/{id}/trace tenantSerialsGetUnitsByIdTrace

Human Supabase USER only; permissions inventory.read, inventory.serials.read. The history of one physical unit: every movement and every reservation event that exists for it, in causal order, each with where it happened and the documents behind it. Documents are related by identifiers only. Each document is named only to a reader who holds the read permission of its module at the time of the request (purchases.read for bills, purchase orders, receipts and supplier returns; sales.read for sales invoices, sales orders and till receipts; accounting.read for journal entries; transfer and import orders with inventory.read). Without it the fact stays and the module is listed in `withheld`; opening a document is authorised again by its own endpoint. A unit of another company is not found.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/units/{id}/trace' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta

Inventory units

GET /tenants/{tenantId}/inventory/units tenantSerialsListUnits

USER with active membership and current permissions inventory.read,inventory.serials.read. Cursor UUIDv7 default50/max100; exact indexed serial/IMEI lookup, at most one identity selector. Tenant-owned units across statuses; no FTS or substring. Machine queries reject warehouseId. Human workspace filters are combined with AND, applied before cursor pagination and tenant/warehouse access controls. Text matching is literal case-insensitive containment. productId includes all variants of the product, including archived variants; document filters never duplicate documents. Date and total bounds are inclusive.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.readinventory.serials.read
Parámetros
tenantId* (path)cursor (query)limit (query)variantId (query)status (query)serialNumber (query)imei (query)search (query)warehouseId (query)productId (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/units' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/units tenantSerialsCreateUnit

USER with active membership and current permissions inventory.adjust. Requires Idempotency-Key and fresh authorization before replay. Unit projection, physical/reservation ledger, audit, receipt and inventory.updated outbox/fanout/queue commit atomically. Write receipt never discloses serial/IMEI; conflicts and stale versions return 409.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.adjust
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/units' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/units/{id} tenantSerialsGetUnit

USER with active membership and current permissions inventory.read,inventory.serials.read.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.readinventory.serials.read
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/units/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/units/{id}/movements tenantSerialsListUnitMovements

USER with active membership and current permissions inventory.read,inventory.serials.read. Physical movements only, quantity 1; reservation records/releases are separate. Unit versions include both streams; reconciliation compares complete source.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.readinventory.serials.read
Parámetros
tenantId* (path)id* (path)cursor (query)limit (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/units/{id}/movements' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/units/{id}/movements tenantSerialsMoveUnit

USER with active membership; operation transaction requires inventory.transfer for TRANSFER, inventory.adjust for all other enabled moves. Requires Idempotency-Key and fresh authorization before replay. Unit projection, physical/reservation ledger, audit, receipt and inventory.updated outbox/fanout/queue commit atomically. Write receipt never discloses serial/IMEI; conflicts and stale versions return 409.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/units/{id}/movements' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/inventory/units/{id}/reservations tenantSerialsReserveUnit

USER with active membership and current permissions inventory.adjust. Requires Idempotency-Key and fresh authorization before replay. Unit projection, physical/reservation ledger, audit, receipt and inventory.updated outbox/fanout/queue commit atomically. Write receipt never discloses serial/IMEI; conflicts and stale versions return 409.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.adjust
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/units/{id}/reservations' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/units/{id}/reconciliation tenantSerialsReconcileUnit

USER with active membership and current permissions inventory.read,inventory.serials.read.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.readinventory.serials.read
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/units/{id}/reconciliation' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/inventory/warehouses/{id}/unit-summary/{variantId} tenantSerialsGetUnitSummary

USER with active membership and current permissions inventory.read. Bounded per-variant warehouse counts by status, at most nine items; no unit IDs or identifiers.

Autenticación
SupabaseBearer · http bearer
required-permissions
inventory.read
Parámetros
tenantId* (path)id* (path)variantId* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/inventory/warehouses/{id}/unit-summary/{variantId}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/inventory/units apiClientSerialsListUnits

API_CLIENT, PUBLIC_API and scopes inventory.read,inventory.serials.read. Dedicated identity reads omit internal location/actor/cost. Cursor UUIDv7 default50/max100; exact indexed serial/IMEI lookup, at most one identity selector. Tenant-owned units across statuses; no FTS or substring. Machine queries reject warehouseId.

Autenticación
PlatformApiKey · http bearer
required-scopes
inventory.readinventory.serials.read
Parámetros
cursor (query)limit (query)variantId (query)status (query)serialNumber (query)imei (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/inventory/units' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/inventory/units apiClientSerialsCreateUnit

API_CLIENT, PUBLIC_API and scopes inventory.write. Dedicated identity reads omit internal location/actor/cost. Requires Idempotency-Key and fresh authorization before replay. Unit projection, physical/reservation ledger, audit, receipt and inventory.updated outbox/fanout/queue commit atomically. Write receipt never discloses serial/IMEI; conflicts and stale versions return 409.

Autenticación
PlatformApiKey · http bearer
required-scopes
inventory.write
Parámetros
Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/inventory/units' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/inventory/units/{id} apiClientSerialsGetUnit

API_CLIENT, PUBLIC_API and scopes inventory.read,inventory.serials.read. Dedicated identity reads omit internal location/actor/cost.

Autenticación
PlatformApiKey · http bearer
required-scopes
inventory.readinventory.serials.read
Parámetros
id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/inventory/units/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/inventory/units/{id}/movements apiClientSerialsMoveUnit

API_CLIENT, PUBLIC_API and scopes inventory.write. Dedicated identity reads omit internal location/actor/cost. Requires Idempotency-Key and fresh authorization before replay. Unit projection, physical/reservation ledger, audit, receipt and inventory.updated outbox/fanout/queue commit atomically. Write receipt never discloses serial/IMEI; conflicts and stale versions return 409.

Autenticación
PlatformApiKey · http bearer
required-scopes
inventory.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/inventory/units/{id}/movements' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/inventory/units/{id}/reservations apiClientSerialsReserveUnit

API_CLIENT, PUBLIC_API and scopes inventory.write. Dedicated identity reads omit internal location/actor/cost. Requires Idempotency-Key and fresh authorization before replay. Unit projection, physical/reservation ledger, audit, receipt and inventory.updated outbox/fanout/queue commit atomically. Write receipt never discloses serial/IMEI; conflicts and stale versions return 409.

Autenticación
PlatformApiKey · http bearer
required-scopes
inventory.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/inventory/units/{id}/reservations' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta

Procurement

GET /tenants/{tenantId}/purchases/suppliers tenantListSuppliers

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.read
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/suppliers' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/suppliers tenantCreateSupplier

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.create
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/suppliers' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/suppliers/{id} tenantGetSupplier

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.read
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/suppliers/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/purchases/suppliers/{id} tenantUpdateSupplier

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.create
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/suppliers/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/suppliers/{id}/archive tenantArchiveSupplier

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.create
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/suppliers/{id}/archive' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/orders tenantListOrders

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI. Human workspace filters are combined with AND, applied before cursor pagination and tenant/warehouse access controls. Text matching is literal case-insensitive containment. productId includes all variants of the product, including archived variants; document filters never duplicate documents. Date and total bounds are inclusive.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.read
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)productId (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/orders' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/orders tenantCreateOrder

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.create
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/orders' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/orders/{id} tenantGetOrder

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.read
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/orders/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/purchases/orders/{id} tenantUpdateOrder

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.create
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/orders/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/orders/{id}/approve tenantApproveOrder

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.approve
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/orders/{id}/approve' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/orders/{id}/cancel tenantCancelOrder

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.approve
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/orders/{id}/cancel' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/orders/{id}/receipts tenantListReceipts

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.read
Parámetros
tenantId* (path)id* (path)limit (query)cursor (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/orders/{id}/receipts' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/orders/{id}/receipts tenantReceiveOrder

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.createinventory.adjust
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/orders/{id}/receipts' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/receipts/{id} tenantGetReceipt

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.read
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/receipts/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/incoming tenantPurchaseIncoming

USER requires active membership and fresh permissions. Supplier management uses purchases.read/create; approval/cancellation requires purchases.approve. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.read
Parámetros
tenantId* (path)limit (query)cursor (query)warehouseId (query)variantId (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/incoming' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/purchases/suppliers apiClientListSuppliers

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
suppliers.read
Parámetros
limit (query)cursor (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/purchases/suppliers' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/purchases/suppliers apiClientCreateSupplier

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
suppliers.write
Parámetros
Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/purchases/suppliers' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/purchases/suppliers/{id} apiClientGetSupplier

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
suppliers.read
Parámetros
id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/purchases/suppliers/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /api-client/purchases/suppliers/{id} apiClientUpdateSupplier

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
suppliers.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/api-client/purchases/suppliers/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/purchases/suppliers/{id}/archive apiClientArchiveSupplier

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
suppliers.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/purchases/suppliers/{id}/archive' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/purchases/orders apiClientListOrders

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.read
Parámetros
limit (query)cursor (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/purchases/orders' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/purchases/orders apiClientCreateOrder

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.write
Parámetros
Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/purchases/orders' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/purchases/orders/{id} apiClientGetOrder

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.read
Parámetros
id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/purchases/orders/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /api-client/purchases/orders/{id} apiClientUpdateOrder

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/api-client/purchases/orders/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/purchases/orders/{id}/approve apiClientApproveOrder

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/purchases/orders/{id}/approve' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/purchases/orders/{id}/cancel apiClientCancelOrder

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/purchases/orders/{id}/cancel' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/purchases/orders/{id}/receipts apiClientListReceipts

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.read
Parámetros
id* (path)limit (query)cursor (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/purchases/orders/{id}/receipts' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/purchases/orders/{id}/receipts apiClientReceiveOrder

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.writeinventory.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/purchases/orders/{id}/receipts' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/purchases/receipts/{id} apiClientGetReceipt

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.read
Parámetros
id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/purchases/receipts/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/purchases/incoming apiClientPurchaseIncoming

API_CLIENT requires explicit scopes and PUBLIC_API; tenant from key. Internal procurement drafts and costs are available only through purchase scopes; custody/actor/tenant metadata omitted. Drafts can be fully replaced with expectedVersion; approval fixes the snapshot. Receipts require purchase creation/write AND Inventory adjustment/write. They atomically append PURCHASE_RECEIPT movements/new serial units, preserve exact costs, update received/pending projections, audit, replay and outbox. No excess receipt, reused serial identity, direct stock edits, unit identifiers in receipt DTOs, valuation, FX, tax, invoice or payment. Services/untracked lines use administrative acceptance without inventory effects. Cancel an open order to stop outstanding incoming; previously posted receipts remain. Lists use UUIDv7 cursor50/max100; incoming is outstanding per open approved order line, excludes drafts/cancelled. Decimals are strings: costs/quantities scale6, quantity*cost totals scale12 without rounding. Up to100 distinct lines and100 units total per receipt. Order number+LegalEntity are immutable; supplier code remains reserved. No anonymous access or business UI.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.read
Parámetros
limit (query)cursor (query)warehouseId (query)variantId (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/purchases/incoming' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/bills tenantPurchasesGetBills

Human Supabase USER only; permissions purchases.read. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion. Human workspace filters are combined with AND, applied before cursor pagination and tenant/warehouse access controls. Text matching is literal case-insensitive containment. productId includes all variants of the product, including archived variants; document filters never duplicate documents. Date and total bounds are inclusive.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)partyId (query)orderId (query)open (query)productId (query)number (query)dateFrom (query)dateTo (query)totalMin (query)totalMax (query)warehouseId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/bills' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/bills tenantPurchasesPostBills

Human Supabase USER only; permissions purchases.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/bills' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/bills/{id} tenantPurchasesGetBillsById

Human Supabase USER only; permissions purchases.read. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/bills/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/purchases/bills/{id} tenantPurchasesPutBillsById

Human Supabase USER only; permissions purchases.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/bills/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/bills/{id}/issue tenantPurchasesPostBillsByIdIssue

Human Supabase USER only; permissions purchases.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/bills/{id}/issue' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/bills/{id}/void tenantPurchasesPostBillsByIdVoid

Human Supabase USER only; permissions purchases.approve. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/bills/{id}/void' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/payments tenantPurchasesGetPayments

Human Supabase USER only; permissions purchases.read. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)partyId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/payments' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/payments tenantPurchasesPostPayments

Human Supabase USER only; permissions purchases.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/payments' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/payments/{id} tenantPurchasesGetPaymentsById

Human Supabase USER only; permissions purchases.read. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/payments/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/payments/{id}/apply tenantPurchasesPostPaymentsByIdApply

Human Supabase USER only; permissions purchases.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/payments/{id}/apply' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/payments/{id}/confirm tenantPurchasesPostPaymentsByIdConfirm

Human Supabase USER only; permissions purchases.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/payments/{id}/confirm' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/payments/{id}/void tenantPurchasesPostPaymentsByIdVoid

Human Supabase USER only; permissions purchases.approve. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/payments/{id}/void' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/bills/{id}/recognize-expense tenantPurchasesPostBillsByIdRecognizeExpense

Human Supabase USER only; permissions purchases.read, accounting.post. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/bills/{id}/recognize-expense' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/credits tenantPurchasesGetCredits

Human Supabase USER only; permissions purchases.read. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)partyId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/credits' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/credits tenantPurchasesPostCredits

Human Supabase USER only; permissions purchases.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/credits' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/credits/{id} tenantPurchasesGetCreditsById

Human Supabase USER only; permissions purchases.read. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/credits/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/purchases/credits/{id} tenantPurchasesPutCreditsById

Human Supabase USER only; permissions purchases.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/credits/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/credits/{id}/recognize tenantPurchasesPostCreditsByIdRecognize

Human Supabase USER only; permissions purchases.approve. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/credits/{id}/recognize' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/credits/{id}/reject tenantPurchasesPostCreditsByIdReject

Human Supabase USER only; permissions purchases.approve. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/credits/{id}/reject' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/credits/{id}/void tenantPurchasesPostCreditsByIdVoid

Human Supabase USER only; permissions purchases.approve. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/credits/{id}/void' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/credits/{id}/apply tenantPurchasesPostCreditsByIdApply

Human Supabase USER only; permissions purchases.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/credits/{id}/apply' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/credits/{id}/refunds tenantPurchasesPostCreditsByIdRefunds

Human Supabase USER only; permissions purchases.approve. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/credits/{id}/refunds' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/returns tenantPurchasesGetReturns

Human Supabase USER only; permissions purchases.read. Physical return of goods to a supplier from one warehouse. DRAFT is editable, AUTHORIZED is frozen, SHIPPED is final; cancelling is possible only before shipping. Authorising moves nothing. Shipping sends the whole return once through the inventory ledger as SUPPLIER_RETURN; serialized lines name the exact units, which leave custody as RETURNED and keep their identity. A return never creates, recognises or applies a credit. No costs, valuation or carrier data. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)supplierId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/returns' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/returns tenantPurchasesPostReturns

Human Supabase USER only; permissions purchases.create. Physical return of goods to a supplier from one warehouse. DRAFT is editable, AUTHORIZED is frozen, SHIPPED is final; cancelling is possible only before shipping. Authorising moves nothing. Shipping sends the whole return once through the inventory ledger as SUPPLIER_RETURN; serialized lines name the exact units, which leave custody as RETURNED and keep their identity. A return never creates, recognises or applies a credit. No costs, valuation or carrier data. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/returns' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/returns/{id} tenantPurchasesGetReturnsById

Human Supabase USER only; permissions purchases.read. Physical return of goods to a supplier from one warehouse. DRAFT is editable, AUTHORIZED is frozen, SHIPPED is final; cancelling is possible only before shipping. Authorising moves nothing. Shipping sends the whole return once through the inventory ledger as SUPPLIER_RETURN; serialized lines name the exact units, which leave custody as RETURNED and keep their identity. A return never creates, recognises or applies a credit. No costs, valuation or carrier data. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/returns/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/purchases/returns/{id} tenantPurchasesPutReturnsById

Human Supabase USER only; permissions purchases.create. Physical return of goods to a supplier from one warehouse. DRAFT is editable, AUTHORIZED is frozen, SHIPPED is final; cancelling is possible only before shipping. Authorising moves nothing. Shipping sends the whole return once through the inventory ledger as SUPPLIER_RETURN; serialized lines name the exact units, which leave custody as RETURNED and keep their identity. A return never creates, recognises or applies a credit. No costs, valuation or carrier data. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/returns/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/returns/{id}/authorize tenantPurchasesPostReturnsByIdAuthorize

Human Supabase USER only; permissions purchases.approve. Physical return of goods to a supplier from one warehouse. DRAFT is editable, AUTHORIZED is frozen, SHIPPED is final; cancelling is possible only before shipping. Authorising moves nothing. Shipping sends the whole return once through the inventory ledger as SUPPLIER_RETURN; serialized lines name the exact units, which leave custody as RETURNED and keep their identity. A return never creates, recognises or applies a credit. No costs, valuation or carrier data. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/returns/{id}/authorize' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/returns/{id}/cancel tenantPurchasesPostReturnsByIdCancel

Human Supabase USER only; permissions purchases.create. Physical return of goods to a supplier from one warehouse. DRAFT is editable, AUTHORIZED is frozen, SHIPPED is final; cancelling is possible only before shipping. Authorising moves nothing. Shipping sends the whole return once through the inventory ledger as SUPPLIER_RETURN; serialized lines name the exact units, which leave custody as RETURNED and keep their identity. A return never creates, recognises or applies a credit. No costs, valuation or carrier data. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/returns/{id}/cancel' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/returns/{id}/ship tenantPurchasesPostReturnsByIdShip

Human Supabase USER only; permissions purchases.create, inventory.adjust. Physical return of goods to a supplier from one warehouse. DRAFT is editable, AUTHORIZED is frozen, SHIPPED is final; cancelling is possible only before shipping. Authorising moves nothing. Shipping sends the whole return once through the inventory ledger as SUPPLIER_RETURN; serialized lines name the exact units, which leave custody as RETURNED and keep their identity. A return never creates, recognises or applies a credit. No costs, valuation or carrier data. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/returns/{id}/ship' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/bills/{id}/confirm-receipt tenantPurchasesPostBillsByIdConfirmReceipt

Human Supabase USER only; permissions purchases.create, purchases.approve, inventory.adjust (403 FULFILMENT_PERMISSION_DENIED names the ones lacking). An invoice carries the physical units of its serialized lines. A supplier bill without a purchase order types the devices it will receive (IMEI 1, IMEI 2, serial number: two IMEI of one phone are one unit); a bill of a purchase order names units that order already received; a sales invoice without an order names the units its direct sale will deliver. Saving any of it reserves and moves nothing, and a draft may be incomplete; posting is not: each serialized line names exactly as many units as it bills (409 UNIT_COUNT_MISMATCH, with `required` and `identified` at the place of each line), and issuing alone is refused for an invoice with no order behind it (409 FULFILMENT_REQUIRED). Confirming with the receipt writes, in one transaction, the purchase with its usual documents (order, approval, receipt in the bill warehouse), one unit and one entry movement per device, the units on the bill lines, and the issue; confirming with the delivery writes the sale with its usual documents (order at the list price, confirmation that reserves the chosen units, delivery), and the issue; for an invoice of an order already confirmed it delivers what that order reserved. Valuation and accounting follow from those movements and from the issue as they always do, and a failure leaves nothing. A sales invoice of an order shows the units the order reserved or delivered and, from the instant it is issued, keeps them as its own: they are never chosen again, they stay on the invoice whatever becomes of the order (a unit its order let go afterwards reads RELEASED), and a sale collected at the register is never delivered, collected or posted twice. Whoever lacks what a receipt or a delivery takes beyond writing the invoice is told which permissions (403 FULFILMENT_PERMISSION_DENIED, one place per permission under `/permissions`): issuing alone is never the alternative. Quantity articles and services have no units here. No taxes, fiscal issue or returns.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/bills/{id}/confirm-receipt' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/bills/{id}/received-units tenantPurchasesPostBillsByIdReceivedUnits

Human Supabase USER only; permissions purchases.create. Names, on a bill issued before units were required, units its purchase order received; the bill, its amounts and its version do not change. A bill is no longer issued short of units, and a receipt adds none to an issued bill by itself. An invoice carries the physical units of its serialized lines. A supplier bill without a purchase order types the devices it will receive (IMEI 1, IMEI 2, serial number: two IMEI of one phone are one unit); a bill of a purchase order names units that order already received; a sales invoice without an order names the units its direct sale will deliver. Saving any of it reserves and moves nothing, and a draft may be incomplete; posting is not: each serialized line names exactly as many units as it bills (409 UNIT_COUNT_MISMATCH, with `required` and `identified` at the place of each line), and issuing alone is refused for an invoice with no order behind it (409 FULFILMENT_REQUIRED). Confirming with the receipt writes, in one transaction, the purchase with its usual documents (order, approval, receipt in the bill warehouse), one unit and one entry movement per device, the units on the bill lines, and the issue; confirming with the delivery writes the sale with its usual documents (order at the list price, confirmation that reserves the chosen units, delivery), and the issue; for an invoice of an order already confirmed it delivers what that order reserved. Valuation and accounting follow from those movements and from the issue as they always do, and a failure leaves nothing. A sales invoice of an order shows the units the order reserved or delivered and, from the instant it is issued, keeps them as its own: they are never chosen again, they stay on the invoice whatever becomes of the order (a unit its order let go afterwards reads RELEASED), and a sale collected at the register is never delivered, collected or posted twice. Whoever lacks what a receipt or a delivery takes beyond writing the invoice is told which permissions (403 FULFILMENT_PERMISSION_DENIED, one place per permission under `/permissions`): issuing alone is never the alternative. Quantity articles and services have no units here. No taxes, fiscal issue or returns.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/bills/{id}/received-units' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/orders/{id}/received-units tenantPurchasesGetOrdersByIdReceivedUnits

Human Supabase USER only; permissions purchases.read, inventory.read, inventory.serials.read. An invoice carries the physical units of its serialized lines. A supplier bill without a purchase order types the devices it will receive (IMEI 1, IMEI 2, serial number: two IMEI of one phone are one unit); a bill of a purchase order names units that order already received; a sales invoice without an order names the units its direct sale will deliver. Saving any of it reserves and moves nothing, and a draft may be incomplete; posting is not: each serialized line names exactly as many units as it bills (409 UNIT_COUNT_MISMATCH, with `required` and `identified` at the place of each line), and issuing alone is refused for an invoice with no order behind it (409 FULFILMENT_REQUIRED). Confirming with the receipt writes, in one transaction, the purchase with its usual documents (order, approval, receipt in the bill warehouse), one unit and one entry movement per device, the units on the bill lines, and the issue; confirming with the delivery writes the sale with its usual documents (order at the list price, confirmation that reserves the chosen units, delivery), and the issue; for an invoice of an order already confirmed it delivers what that order reserved. Valuation and accounting follow from those movements and from the issue as they always do, and a failure leaves nothing. A sales invoice of an order shows the units the order reserved or delivered and, from the instant it is issued, keeps them as its own: they are never chosen again, they stay on the invoice whatever becomes of the order (a unit its order let go afterwards reads RELEASED), and a sale collected at the register is never delivered, collected or posted twice. Whoever lacks what a receipt or a delivery takes beyond writing the invoice is told which permissions (403 FULFILMENT_PERMISSION_DENIED, one place per permission under `/permissions`): issuing alone is never the alternative. Quantity articles and services have no units here. No taxes, fiscal issue or returns.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)variantId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/orders/{id}/received-units' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta

Sales

GET /tenants/{tenantId}/sales/customers tenantSalesGetCustomers

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.read
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/customers' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/customers tenantSalesPostCustomers

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.create
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/customers' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/sales/customers/{id} tenantSalesGetCustomers_id

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.read
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/customers/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/sales/customers/{id} tenantSalesPutCustomers_id

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.create
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/customers/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/customers/{id}/archive tenantSalesPostCustomers_id_archive

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.create
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/customers/{id}/archive' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/sales/orders tenantSalesGetOrders

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS. Human workspace filters are combined with AND, applied before cursor pagination and tenant/warehouse access controls. Text matching is literal case-insensitive containment. productId includes all variants of the product, including archived variants; document filters never duplicate documents. Date and total bounds are inclusive.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.read
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)productId (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/orders' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/orders tenantSalesPostOrders

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.create
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/orders' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/sales/orders/{id} tenantSalesGetOrders_id

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.read
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/orders/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/sales/orders/{id} tenantSalesPutOrders_id

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.create
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/orders/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/orders/{id}/confirm tenantSalesPostOrders_id_confirm

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.approve
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/orders/{id}/confirm' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/orders/{id}/cancel tenantSalesPostOrders_id_cancel

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.approve
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/orders/{id}/cancel' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/orders/{id}/complete tenantSalesPostOrders_id_complete

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
SupabaseBearer · http bearer
required-permissions
purchases.approve
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/orders/{id}/complete' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/sales/customers apiSalesGetCustomers

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
PlatformApiKey · http bearer
required-scopes
suppliers.read
Parámetros
limit (query)cursor (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/sales/customers' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/sales/customers apiSalesPostCustomers

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
PlatformApiKey · http bearer
required-scopes
suppliers.write
Parámetros
Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/sales/customers' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/sales/customers/{id} apiSalesGetCustomers_id

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
PlatformApiKey · http bearer
required-scopes
suppliers.read
Parámetros
id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/sales/customers/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /api-client/sales/customers/{id} apiSalesPutCustomers_id

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
PlatformApiKey · http bearer
required-scopes
suppliers.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/api-client/sales/customers/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/sales/customers/{id}/archive apiSalesPostCustomers_id_archive

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
PlatformApiKey · http bearer
required-scopes
suppliers.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/sales/customers/{id}/archive' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/sales/orders apiSalesGetOrders

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.read
Parámetros
limit (query)cursor (query)status (query)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/sales/orders' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/sales/orders apiSalesPostOrders

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.write
Parámetros
Idempotency-Key* (header)
Respuestas
201400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/sales/orders' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /api-client/sales/orders/{id} apiSalesGetOrders_id

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.read
Parámetros
id* (path)
Respuestas
200400401403404409413429500503 
curl --request GET \
  --url 'https://api.marky.ec/v1/api-client/sales/orders/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /api-client/sales/orders/{id} apiSalesPutOrders_id

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/api-client/sales/orders/{id}' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/sales/orders/{id}/confirm apiSalesPostOrders_id_confirm

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/sales/orders/{id}/confirm' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/sales/orders/{id}/cancel apiSalesPostOrders_id_cancel

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/sales/orders/{id}/cancel' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /api-client/sales/orders/{id}/complete apiSalesPostOrders_id_complete

Tenant-scoped sales with fresh USER RBAC or API_CLIENT scopes and PUBLIC_API entitlement. Customers require customers.read/write. Orders require sales.read; draft writes require sales.create (machine sales.write) plus pricing.read. Confirmation adds inventory.adjust (machine inventory.write), refreshes current prices, freezes snapshots and reserves all stock/selected unit UUIDs. Completion requires sales.create+inventory.adjust (machine sales.write+inventory.write) and atomically consumes reservations and appends SALE movements; serialized units become SOLD without custody. Cancellation requires sales.cancel+inventory.adjust (machine sales.write+inventory.write) and releases reservations without reversing physical movements. State DRAFT→CONFIRMED→COMPLETED or cancellation before completion; expectedVersion mandatory. Single legal entity, warehouse and price-list currency per order; at most100 distinct lines and100 serial units. Decimal quantities/prices scale6, unrounded commercial totals scale12. All writes require Idempotency-Key; replay is denied after permission/scope/entitlement revocation. Machine pricing accepts public lists and published active variants. No anonymous access, purchase costs/margins, serial identities, payment, tax, invoice, return or UI in the Sales endpoints; cash checkout composes delivery through POS.

Autenticación
PlatformApiKey · http bearer
required-scopes
purchases.write
Parámetros
id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409413429500503 
curl --request POST \
  --url 'https://api.marky.ec/v1/api-client/sales/orders/{id}/complete' \
  --header 'Authorization: Bearer <PlatformApiKey>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/sales/quotations tenantSalesGetQuotations

Human Supabase USER only; permissions sales.read. A quotation is a proposal with an exact list-price snapshot: it never reserves, deducts or delivers stock. DRAFT is editable and re-priced on every save; ISSUED is frozen; ACCEPTED, REJECTED and CANCELLED are final. Issuing requires every snapshot to equal the current list price. Accepting is refused after validUntil and may originate one draft sales order with the quoted lines, only while list prices still equal the quoted prices; reserving, collecting and delivering stay explicit sales order and POS actions. No discounts, taxes, negotiated prices, fiscal documents or sending. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)customerId (query)salesOrderId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/quotations' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/quotations tenantSalesPostQuotations

Human Supabase USER only; permissions sales.create, pricing.read. A quotation is a proposal with an exact list-price snapshot: it never reserves, deducts or delivers stock. DRAFT is editable and re-priced on every save; ISSUED is frozen; ACCEPTED, REJECTED and CANCELLED are final. Issuing requires every snapshot to equal the current list price. Accepting is refused after validUntil and may originate one draft sales order with the quoted lines, only while list prices still equal the quoted prices; reserving, collecting and delivering stay explicit sales order and POS actions. No discounts, taxes, negotiated prices, fiscal documents or sending. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/quotations' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/sales/quotations/{id} tenantSalesGetQuotationsById

Human Supabase USER only; permissions sales.read. A quotation is a proposal with an exact list-price snapshot: it never reserves, deducts or delivers stock. DRAFT is editable and re-priced on every save; ISSUED is frozen; ACCEPTED, REJECTED and CANCELLED are final. Issuing requires every snapshot to equal the current list price. Accepting is refused after validUntil and may originate one draft sales order with the quoted lines, only while list prices still equal the quoted prices; reserving, collecting and delivering stay explicit sales order and POS actions. No discounts, taxes, negotiated prices, fiscal documents or sending. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/quotations/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/sales/quotations/{id} tenantSalesPutQuotationsById

Human Supabase USER only; permissions sales.create, pricing.read. A quotation is a proposal with an exact list-price snapshot: it never reserves, deducts or delivers stock. DRAFT is editable and re-priced on every save; ISSUED is frozen; ACCEPTED, REJECTED and CANCELLED are final. Issuing requires every snapshot to equal the current list price. Accepting is refused after validUntil and may originate one draft sales order with the quoted lines, only while list prices still equal the quoted prices; reserving, collecting and delivering stay explicit sales order and POS actions. No discounts, taxes, negotiated prices, fiscal documents or sending. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/quotations/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/quotations/{id}/issue tenantSalesPostQuotationsByIdIssue

Human Supabase USER only; permissions sales.create, pricing.read. A quotation is a proposal with an exact list-price snapshot: it never reserves, deducts or delivers stock. DRAFT is editable and re-priced on every save; ISSUED is frozen; ACCEPTED, REJECTED and CANCELLED are final. Issuing requires every snapshot to equal the current list price. Accepting is refused after validUntil and may originate one draft sales order with the quoted lines, only while list prices still equal the quoted prices; reserving, collecting and delivering stay explicit sales order and POS actions. No discounts, taxes, negotiated prices, fiscal documents or sending. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/quotations/{id}/issue' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/quotations/{id}/accept tenantSalesPostQuotationsByIdAccept

Human Supabase USER only; permissions sales.create; pricing.read as well when it originates a sales order. A quotation is a proposal with an exact list-price snapshot: it never reserves, deducts or delivers stock. DRAFT is editable and re-priced on every save; ISSUED is frozen; ACCEPTED, REJECTED and CANCELLED are final. Issuing requires every snapshot to equal the current list price. Accepting is refused after validUntil and may originate one draft sales order with the quoted lines, only while list prices still equal the quoted prices; reserving, collecting and delivering stay explicit sales order and POS actions. No discounts, taxes, negotiated prices, fiscal documents or sending. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/quotations/{id}/accept' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/quotations/{id}/reject tenantSalesPostQuotationsByIdReject

Human Supabase USER only; permissions sales.create. A quotation is a proposal with an exact list-price snapshot: it never reserves, deducts or delivers stock. DRAFT is editable and re-priced on every save; ISSUED is frozen; ACCEPTED, REJECTED and CANCELLED are final. Issuing requires every snapshot to equal the current list price. Accepting is refused after validUntil and may originate one draft sales order with the quoted lines, only while list prices still equal the quoted prices; reserving, collecting and delivering stay explicit sales order and POS actions. No discounts, taxes, negotiated prices, fiscal documents or sending. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/quotations/{id}/reject' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/quotations/{id}/cancel tenantSalesPostQuotationsByIdCancel

Human Supabase USER only; permissions sales.cancel. A quotation is a proposal with an exact list-price snapshot: it never reserves, deducts or delivers stock. DRAFT is editable and re-priced on every save; ISSUED is frozen; ACCEPTED, REJECTED and CANCELLED are final. Issuing requires every snapshot to equal the current list price. Accepting is refused after validUntil and may originate one draft sales order with the quoted lines, only while list prices still equal the quoted prices; reserving, collecting and delivering stay explicit sales order and POS actions. No discounts, taxes, negotiated prices, fiscal documents or sending. Writes are idempotent, versioned and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/quotations/{id}/cancel' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/sales/reservations tenantSalesGetReservations

Human Supabase USER only; permissions sales.read, inventory.read, customers.read. Read-only view of Inventory reservations created by confirmed sales orders, with the order and customer they belong to. Inventory remains the only source of reserved stock; nothing is duplicated.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)customerId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/reservations' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/sales/invoices tenantSalesGetInvoices

Human Supabase USER only; permissions sales.read. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion. Human workspace filters are combined with AND, applied before cursor pagination and tenant/warehouse access controls. Text matching is literal case-insensitive containment. productId includes all variants of the product, including archived variants; document filters never duplicate documents. Date and total bounds are inclusive.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)partyId (query)orderId (query)open (query)productId (query)number (query)dateFrom (query)dateTo (query)totalMin (query)totalMax (query)warehouseId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/invoices' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/invoices tenantSalesPostInvoices

Human Supabase USER only; permissions sales.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/invoices' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/sales/invoices/{id} tenantSalesGetInvoicesById

Human Supabase USER only; permissions sales.read. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/invoices/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/sales/invoices/{id} tenantSalesPutInvoicesById

Human Supabase USER only; permissions sales.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/invoices/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/invoices/{id}/issue tenantSalesPostInvoicesByIdIssue

Human Supabase USER only; permissions sales.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/invoices/{id}/issue' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/invoices/{id}/void tenantSalesPostInvoicesByIdVoid

Human Supabase USER only; permissions sales.cancel. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/invoices/{id}/void' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/invoices/{id}/pos-receipt tenantSalesPostInvoicesByIdPosReceipt

Human Supabase USER only; permissions sales.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/invoices/{id}/pos-receipt' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/sales/payments tenantSalesGetPayments

Human Supabase USER only; permissions sales.read. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)partyId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/payments' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/payments tenantSalesPostPayments

Human Supabase USER only; permissions sales.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/payments' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/sales/payments/{id} tenantSalesGetPaymentsById

Human Supabase USER only; permissions sales.read. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/payments/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/payments/{id}/apply tenantSalesPostPaymentsByIdApply

Human Supabase USER only; permissions sales.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/payments/{id}/apply' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/payments/{id}/confirm tenantSalesPostPaymentsByIdConfirm

Human Supabase USER only; permissions sales.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/payments/{id}/confirm' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/payments/{id}/void tenantSalesPostPaymentsByIdVoid

Human Supabase USER only; permissions sales.cancel. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/payments/{id}/void' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/invoices/{id}/recognize-revenue tenantSalesPostInvoicesByIdRecognizeRevenue

Human Supabase USER only; permissions sales.read, accounting.post. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/invoices/{id}/recognize-revenue' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/sales/credit-notes tenantSalesGetCreditNotes

Human Supabase USER only; permissions sales.read. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)partyId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/credit-notes' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/credit-notes tenantSalesPostCreditNotes

Human Supabase USER only; permissions sales.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/credit-notes' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/sales/credit-notes/{id} tenantSalesGetCreditNotesById

Human Supabase USER only; permissions sales.read. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/credit-notes/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/sales/credit-notes/{id} tenantSalesPutCreditNotesById

Human Supabase USER only; permissions sales.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/credit-notes/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/credit-notes/{id}/recognize tenantSalesPostCreditNotesByIdRecognize

Human Supabase USER only; permissions sales.cancel. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/credit-notes/{id}/recognize' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/credit-notes/{id}/reject tenantSalesPostCreditNotesByIdReject

Human Supabase USER only; permissions sales.cancel. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/credit-notes/{id}/reject' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/credit-notes/{id}/void tenantSalesPostCreditNotesByIdVoid

Human Supabase USER only; permissions sales.cancel. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/credit-notes/{id}/void' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/credit-notes/{id}/apply tenantSalesPostCreditNotesByIdApply

Human Supabase USER only; permissions sales.create. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/credit-notes/{id}/apply' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/credit-notes/{id}/refunds tenantSalesPostCreditNotesByIdRefunds

Human Supabase USER only; permissions sales.cancel. Commercial documents, not fiscal ones: no tax, fiscal numbering, electronic issuance, rounding or currency conversion. An invoice is DRAFT (editable), ISSUED (frozen) or VOID (only when nothing was applied). Its total is the exact sum of its lines and must fit 6 decimals. Balances are never stored: an invoice balance is its total minus applications; a payment has an unapplied remainder; a credit is REQUESTED until a real document recognises it, and only a RECOGNIZED credit has an available balance, reduced by applications and refunds. Applications are immutable and join documents of the same party, legal entity, currency and side; they never exceed either balance. A payment states its method (cash, transfer, card, cheque, other), for a card whether debit or credit, and may name the money account it lands in or leaves from; a PENDING payment is money announced and not confirmed: it carries no applications and settles nothing until it is confirmed. Card numbers and security codes are never accepted. A sales order collected at the register is settled only by that receipt, recorded once as one payment per payment component, so the collection is never counted twice and linking never brings money in again; the POS records are not changed. Credits and physical returns are independent: neither creates the other, and naming a variant or unit moves no inventory. Saving or issuing an invoice moves none either: the devices typed on a bill and the units chosen on a sales invoice are only what its lines carry, until the invoice is confirmed together with its receipt or its delivery (see those operations). A draft may be incomplete. An invoice is posted (issued, confirmed or recognised) only with every unit of every line of a serialized article identified and linked to it, exactly as many as the line bills, and it is never completed afterwards. How an article is tracked is read from its product, whatever the request says; a line that names a physical unit without its SKU is a line of a serialized article too (409 FULFILMENT_INCOMPLETE). Issuing alone therefore works for a bill whose purchase order already received the units its lines name, and for a sales invoice whose order reserved or delivered them, the sales of the register included: the invoice keeps those units from the instant it is issued, and nothing enters or leaves again. An invoice with no order behind it that bills a serialized article is not issued alone, whatever it carries and with or without a price list (409 FULFILMENT_REQUIRED): it is confirmed together with its receipt or its delivery. A line short of units is refused with 409 UNIT_COUNT_MISMATCH. Each place in `errors` says how many units the line bills (`required`) and how many are identified (`identified`): counts, never an identifier. Recognising revenue or expense by decision is refused the same way for an invoice that bills a serialized article. Quantity articles and services need no units and behave as before. A credit is financial unless a supplier credit states COST_CORRECTION and names the receipt lines it corrects: only then does recognising it change what those goods are worth, where they still are, and never by more than they cost. A stated money account is validated against the active accounts of the entity that fit the method (PAYMENT_ACCOUNT_INVALID). Cash refunded to a customer from the cash account of the tills names the open session it leaves (CASH_SESSION_REQUIRED): the refund lowers the expected cash of that session and posts one entry; cash from anywhere else names another cash account and touches no session. When the legal entity keeps books, issuing, paying, applying, recognising and refunding each post their entry in the same transaction or fail with ACCOUNTING_SETUP_REQUIRED, ACCOUNTING_PERIOD_CLOSED, ACCOUNTING_CURRENCY_UNSUPPORTED or ACCOUNTING_AMOUNT_PRECISION; voiding posts the mirror entry. An invoice never recognises revenue by itself: revenue is earned on delivery of its order, or by an explicit recognition when it has no order. Writes are idempotent and tenant scoped; state changes carry expectedVersion.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/credit-notes/{id}/refunds' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/sales/invoices/{id}/confirm-delivery tenantSalesPostInvoicesByIdConfirmDelivery

Human Supabase USER only; permissions sales.create, pricing.read, inventory.adjust (403 FULFILMENT_PERMISSION_DENIED names the ones lacking). An invoice carries the physical units of its serialized lines. A supplier bill without a purchase order types the devices it will receive (IMEI 1, IMEI 2, serial number: two IMEI of one phone are one unit); a bill of a purchase order names units that order already received; a sales invoice without an order names the units its direct sale will deliver. Saving any of it reserves and moves nothing, and a draft may be incomplete; posting is not: each serialized line names exactly as many units as it bills (409 UNIT_COUNT_MISMATCH, with `required` and `identified` at the place of each line), and issuing alone is refused for an invoice with no order behind it (409 FULFILMENT_REQUIRED). Confirming with the receipt writes, in one transaction, the purchase with its usual documents (order, approval, receipt in the bill warehouse), one unit and one entry movement per device, the units on the bill lines, and the issue; confirming with the delivery writes the sale with its usual documents (order at the list price, confirmation that reserves the chosen units, delivery), and the issue; for an invoice of an order already confirmed it delivers what that order reserved. Valuation and accounting follow from those movements and from the issue as they always do, and a failure leaves nothing. A sales invoice of an order shows the units the order reserved or delivered and, from the instant it is issued, keeps them as its own: they are never chosen again, they stay on the invoice whatever becomes of the order (a unit its order let go afterwards reads RELEASED), and a sale collected at the register is never delivered, collected or posted twice. Whoever lacks what a receipt or a delivery takes beyond writing the invoice is told which permissions (403 FULFILMENT_PERMISSION_DENIED, one place per permission under `/permissions`): issuing alone is never the alternative. Quantity articles and services have no units here. No taxes, fiscal issue or returns.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/invoices/{id}/confirm-delivery' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/sales/price-adjustments tenantSalesGetPriceAdjustments

Human Supabase USER only; permissions sales.read. A sale line is priced by its list unless a person agrees another price: the unit price itself or a discount on the list price, never both. Agreeing a price takes sales.price.override, besides the permission to write the document, and a reason; the server checks it and records who changed the price, the price before, the list price and why. Without the permission the list price is used. An agreed price is a snapshot: an accepted quotation hands it to its order, the order keeps it when it is confirmed and delivered, its invoice bills it and the register collects it; a later change of the price list changes none of them, and the price list itself is never changed by a sale. A line at the list price keeps taking the list price in force when its order is confirmed, as before. The invoice and the order written from it carry the same quantities, agreed prices, currency and total. An agreed price changes the sale amount only: never the cost or the valuation of what is sold. API clients state no prices. This read lists every change of an agreed price of one sale document (a quotation, a sales order or a sales invoice) together with those of the documents it comes from or was written into, oldest first.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)documentId* (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/sales/price-adjustments?documentId=<documentId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta

POS

GET /tenants/{tenantId}/pos/registers tenantPosGetRegisters

Human Supabase USER only; permissions sales.read. One open operator-bound session per register. Configuration immutable except archive without an open session. Checkout accepts only a confirmed Sales order matching entity/warehouse/list/currency, checks both versions and cash precision, and atomically delivers Sales, consumes Inventory reservations, inserts one immutable receipt with its payment components and increments the session version. The sale is collected in full with cash, transfer, debit or credit card, cheque or other methods, alone or mixed; components add up to the total exactly, change is given only in cash and is exact, and collections made on an external terminal or bank are recorded: no acquirer is contacted and no card number or security code is accepted. No partial delivery, credit sale, fiscal invoice, taxes, discount, rounding, FX or refunds. Cash entering or leaving the till outside a sale is a cash movement. Closing records expected cash (opening amount, cash portions of sales and cash movements; never cards or transfers), counted cash and signed variance; no reopening. All writes are idempotent and all reads/writes tenant scoped. Events expose IDs only.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pos/registers' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/pos/registers tenantPosPostRegisters

Human Supabase USER only; permissions settings.manage. One open operator-bound session per register. Configuration immutable except archive without an open session. Checkout accepts only a confirmed Sales order matching entity/warehouse/list/currency, checks both versions and cash precision, and atomically delivers Sales, consumes Inventory reservations, inserts one immutable receipt with its payment components and increments the session version. The sale is collected in full with cash, transfer, debit or credit card, cheque or other methods, alone or mixed; components add up to the total exactly, change is given only in cash and is exact, and collections made on an external terminal or bank are recorded: no acquirer is contacted and no card number or security code is accepted. No partial delivery, credit sale, fiscal invoice, taxes, discount, rounding, FX or refunds. Cash entering or leaving the till outside a sale is a cash movement. Closing records expected cash (opening amount, cash portions of sales and cash movements; never cards or transfers), counted cash and signed variance; no reopening. All writes are idempotent and all reads/writes tenant scoped. Events expose IDs only.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pos/registers' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/pos/registers/{id} tenantPosGetRegistersById

Human Supabase USER only; permissions sales.read. One open operator-bound session per register. Configuration immutable except archive without an open session. Checkout accepts only a confirmed Sales order matching entity/warehouse/list/currency, checks both versions and cash precision, and atomically delivers Sales, consumes Inventory reservations, inserts one immutable receipt with its payment components and increments the session version. The sale is collected in full with cash, transfer, debit or credit card, cheque or other methods, alone or mixed; components add up to the total exactly, change is given only in cash and is exact, and collections made on an external terminal or bank are recorded: no acquirer is contacted and no card number or security code is accepted. No partial delivery, credit sale, fiscal invoice, taxes, discount, rounding, FX or refunds. Cash entering or leaving the till outside a sale is a cash movement. Closing records expected cash (opening amount, cash portions of sales and cash movements; never cards or transfers), counted cash and signed variance; no reopening. All writes are idempotent and all reads/writes tenant scoped. Events expose IDs only.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pos/registers/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/pos/registers/{id}/archive tenantPosPostRegistersByIdArchive

Human Supabase USER only; permissions settings.manage. One open operator-bound session per register. Configuration immutable except archive without an open session. Checkout accepts only a confirmed Sales order matching entity/warehouse/list/currency, checks both versions and cash precision, and atomically delivers Sales, consumes Inventory reservations, inserts one immutable receipt with its payment components and increments the session version. The sale is collected in full with cash, transfer, debit or credit card, cheque or other methods, alone or mixed; components add up to the total exactly, change is given only in cash and is exact, and collections made on an external terminal or bank are recorded: no acquirer is contacted and no card number or security code is accepted. No partial delivery, credit sale, fiscal invoice, taxes, discount, rounding, FX or refunds. Cash entering or leaving the till outside a sale is a cash movement. Closing records expected cash (opening amount, cash portions of sales and cash movements; never cards or transfers), counted cash and signed variance; no reopening. All writes are idempotent and all reads/writes tenant scoped. Events expose IDs only.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pos/registers/{id}/archive' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/pos/sessions tenantPosGetSessions

Human Supabase USER only; permissions sales.read. One open operator-bound session per register. Configuration immutable except archive without an open session. Checkout accepts only a confirmed Sales order matching entity/warehouse/list/currency, checks both versions and cash precision, and atomically delivers Sales, consumes Inventory reservations, inserts one immutable receipt with its payment components and increments the session version. The sale is collected in full with cash, transfer, debit or credit card, cheque or other methods, alone or mixed; components add up to the total exactly, change is given only in cash and is exact, and collections made on an external terminal or bank are recorded: no acquirer is contacted and no card number or security code is accepted. No partial delivery, credit sale, fiscal invoice, taxes, discount, rounding, FX or refunds. Cash entering or leaving the till outside a sale is a cash movement. Closing records expected cash (opening amount, cash portions of sales and cash movements; never cards or transfers), counted cash and signed variance; no reopening. All writes are idempotent and all reads/writes tenant scoped. Events expose IDs only.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)status (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pos/sessions' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/pos/sessions tenantPosPostSessions

Human Supabase USER only; permissions sales.create. One open operator-bound session per register. Configuration immutable except archive without an open session. Checkout accepts only a confirmed Sales order matching entity/warehouse/list/currency, checks both versions and cash precision, and atomically delivers Sales, consumes Inventory reservations, inserts one immutable receipt with its payment components and increments the session version. The sale is collected in full with cash, transfer, debit or credit card, cheque or other methods, alone or mixed; components add up to the total exactly, change is given only in cash and is exact, and collections made on an external terminal or bank are recorded: no acquirer is contacted and no card number or security code is accepted. No partial delivery, credit sale, fiscal invoice, taxes, discount, rounding, FX or refunds. Cash entering or leaving the till outside a sale is a cash movement. Closing records expected cash (opening amount, cash portions of sales and cash movements; never cards or transfers), counted cash and signed variance; no reopening. All writes are idempotent and all reads/writes tenant scoped. Events expose IDs only.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pos/sessions' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/pos/sessions/{id} tenantPosGetSessionsById

Human Supabase USER only; permissions sales.read. One open operator-bound session per register. Configuration immutable except archive without an open session. Checkout accepts only a confirmed Sales order matching entity/warehouse/list/currency, checks both versions and cash precision, and atomically delivers Sales, consumes Inventory reservations, inserts one immutable receipt with its payment components and increments the session version. The sale is collected in full with cash, transfer, debit or credit card, cheque or other methods, alone or mixed; components add up to the total exactly, change is given only in cash and is exact, and collections made on an external terminal or bank are recorded: no acquirer is contacted and no card number or security code is accepted. No partial delivery, credit sale, fiscal invoice, taxes, discount, rounding, FX or refunds. Cash entering or leaving the till outside a sale is a cash movement. Closing records expected cash (opening amount, cash portions of sales and cash movements; never cards or transfers), counted cash and signed variance; no reopening. All writes are idempotent and all reads/writes tenant scoped. Events expose IDs only.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pos/sessions/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/pos/sessions/{id}/close tenantPosPostSessionsByIdClose

Human Supabase USER only; permissions sales.create. One open operator-bound session per register. Configuration immutable except archive without an open session. Checkout accepts only a confirmed Sales order matching entity/warehouse/list/currency, checks both versions and cash precision, and atomically delivers Sales, consumes Inventory reservations, inserts one immutable receipt with its payment components and increments the session version. The sale is collected in full with cash, transfer, debit or credit card, cheque or other methods, alone or mixed; components add up to the total exactly, change is given only in cash and is exact, and collections made on an external terminal or bank are recorded: no acquirer is contacted and no card number or security code is accepted. No partial delivery, credit sale, fiscal invoice, taxes, discount, rounding, FX or refunds. Cash entering or leaving the till outside a sale is a cash movement. Closing records expected cash (opening amount, cash portions of sales and cash movements; never cards or transfers), counted cash and signed variance; no reopening. All writes are idempotent and all reads/writes tenant scoped. Events expose IDs only.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pos/sessions/{id}/close' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/pos/sessions/{id}/checkout tenantPosPostSessionsByIdCheckout

Human Supabase USER only; permissions sales.create, pricing.read, inventory.adjust. One open operator-bound session per register. Configuration immutable except archive without an open session. Checkout accepts only a confirmed Sales order matching entity/warehouse/list/currency, checks both versions and cash precision, and atomically delivers Sales, consumes Inventory reservations, inserts one immutable receipt with its payment components and increments the session version. The sale is collected in full with cash, transfer, debit or credit card, cheque or other methods, alone or mixed; components add up to the total exactly, change is given only in cash and is exact, and collections made on an external terminal or bank are recorded: no acquirer is contacted and no card number or security code is accepted. No partial delivery, credit sale, fiscal invoice, taxes, discount, rounding, FX or refunds. Cash entering or leaving the till outside a sale is a cash movement. Closing records expected cash (opening amount, cash portions of sales and cash movements; never cards or transfers), counted cash and signed variance; no reopening. All writes are idempotent and all reads/writes tenant scoped. Events expose IDs only.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pos/sessions/{id}/checkout' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/pos/receipts tenantPosGetReceipts

Human Supabase USER only; permissions sales.read. One open operator-bound session per register. Configuration immutable except archive without an open session. Checkout accepts only a confirmed Sales order matching entity/warehouse/list/currency, checks both versions and cash precision, and atomically delivers Sales, consumes Inventory reservations, inserts one immutable receipt with its payment components and increments the session version. The sale is collected in full with cash, transfer, debit or credit card, cheque or other methods, alone or mixed; components add up to the total exactly, change is given only in cash and is exact, and collections made on an external terminal or bank are recorded: no acquirer is contacted and no card number or security code is accepted. No partial delivery, credit sale, fiscal invoice, taxes, discount, rounding, FX or refunds. Cash entering or leaving the till outside a sale is a cash movement. Closing records expected cash (opening amount, cash portions of sales and cash movements; never cards or transfers), counted cash and signed variance; no reopening. All writes are idempotent and all reads/writes tenant scoped. Events expose IDs only.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)sessionId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pos/receipts' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/pos/receipts/{id} tenantPosGetReceiptsById

Human Supabase USER only; permissions sales.read. One open operator-bound session per register. Configuration immutable except archive without an open session. Checkout accepts only a confirmed Sales order matching entity/warehouse/list/currency, checks both versions and cash precision, and atomically delivers Sales, consumes Inventory reservations, inserts one immutable receipt with its payment components and increments the session version. The sale is collected in full with cash, transfer, debit or credit card, cheque or other methods, alone or mixed; components add up to the total exactly, change is given only in cash and is exact, and collections made on an external terminal or bank are recorded: no acquirer is contacted and no card number or security code is accepted. No partial delivery, credit sale, fiscal invoice, taxes, discount, rounding, FX or refunds. Cash entering or leaving the till outside a sale is a cash movement. Closing records expected cash (opening amount, cash portions of sales and cash movements; never cards or transfers), counted cash and signed variance; no reopening. All writes are idempotent and all reads/writes tenant scoped. Events expose IDs only.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pos/receipts/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/pos/sessions/{id}/cash-movements tenantPosGetSessionsByIdCashMovements

Human Supabase USER only; permissions sales.read. Cash that enters or leaves a till outside a sale needs pos.cash.move and is booked against another cash or bank account, or an account accounting opened for till movements (cashCounterpart). Cash handed back for a customer credit leaves the till through the refund itself: it lowers the expected cash and posts one entry, the refund. Human Supabase USER only. Counter collection with payment components: cash, transfer, debit or credit card, cheque and other configured methods, alone or mixed. Collections made on an external terminal or bank are recorded; no acquirer is contacted, no charge is made and no card number or security code is accepted or stored. Each component records amount, currency, method, destination account, status and reference; the components add up to the order total exactly, and delivery stays complete: no credit or partial delivery. Change is given only in cash. The cash count expects only cash that physically stayed in the till: opening amount, cash portions of sales and cash movements; cards and transfers are shown apart. When the entity keeps books the collection posts one entry in the same transaction. Writes are idempotent and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pos/sessions/{id}/cash-movements' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/pos/sessions/{id}/cash-movements tenantPosPostSessionsByIdCashMovements

Human Supabase USER only; permissions sales.create and pos.cash.move; only the operator of the open session. 409 CASH_INSUFFICIENT when the till does not hold the cash, 409 PAYMENT_ACCOUNT_INVALID when the account is not one a till movement may use. Cash that enters or leaves a till outside a sale needs pos.cash.move and is booked against another cash or bank account, or an account accounting opened for till movements (cashCounterpart). Cash handed back for a customer credit leaves the till through the refund itself: it lowers the expected cash and posts one entry, the refund. Human Supabase USER only. Counter collection with payment components: cash, transfer, debit or credit card, cheque and other configured methods, alone or mixed. Collections made on an external terminal or bank are recorded; no acquirer is contacted, no charge is made and no card number or security code is accepted or stored. Each component records amount, currency, method, destination account, status and reference; the components add up to the order total exactly, and delivery stays complete: no credit or partial delivery. Change is given only in cash. The cash count expects only cash that physically stayed in the till: opening amount, cash portions of sales and cash movements; cards and transfers are shown apart. When the entity keeps books the collection posts one entry in the same transaction. Writes are idempotent and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/pos/sessions/{id}/cash-movements' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta

Platform administration

GET /platform/tenants listPlatformCompanies

Active human platform administrator only, rechecked inside the database transaction. No authorization from email or client metadata. Tenant isolation still applies to business records.

Autenticación
SupabaseBearer · http bearer
Parámetros
q (query)limit (query)cursor (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/platform/tenants' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /platform/users listPlatformUsers

Active human platform administrator only, rechecked inside the database transaction. No authorization from email or client metadata. Tenant isolation still applies to business records.

Autenticación
SupabaseBearer · http bearer
Parámetros
q (query)limit (query)cursor (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/platform/users' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /platform/plans listPlatformPlans

Active human platform administrator only, rechecked inside the database transaction. No authorization from email or client metadata. Tenant isolation still applies to business records.

Autenticación
SupabaseBearer · http bearer
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/platform/plans' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /platform/tenants/{tenantId} getPlatformCompany

Active human platform administrator only, rechecked inside the database transaction. No authorization from email or client metadata. Tenant isolation still applies to business records.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/platform/tenants/{tenantId}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /platform/tenants/{tenantId}/members listGlobalCompanyMembers

Active human platform administrator only, rechecked inside the database transaction. No authorization from email or client metadata. Tenant isolation still applies to business records.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/platform/tenants/{tenantId}/members' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /platform/tenants/{tenantId}/roles listGlobalCompanyRoles

Active human platform administrator only, rechecked inside the database transaction. No authorization from email or client metadata. Tenant isolation still applies to business records.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/platform/tenants/{tenantId}/roles' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /platform/tenants/{tenantId}/plan assignComplimentaryPlan

Explicit complimentary assignment by an active global administrator. No charge or membership/role change. Expected subscription version, durable tenant-bound idempotency, serialized quotas, retained serial trace and append-only assignment history. FREE/BASIC are refused when serialized inventory exists; a downgrade cannot remove data or exceed its limits. Self-service paid requests remain pending until separately activated.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/platform/tenants/{tenantId}/plan' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta

Reports

GET /tenants/{tenantId}/reports/stock tenantReportsGetStock

Human Supabase USER only; permissions inventory.read, catalog.read. Read-only report computed from the ledgers and documents of the tenant at request time; nothing is stored, estimated or rounded. `legalEntityId` narrows it to one legal entity.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)legalEntityId (query)warehouseId (query)productId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/reports/stock' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/reports/in-transit tenantReportsGetInTransit

Human Supabase USER only; permissions inventory.read, catalog.read. Read-only report computed from the ledgers and documents of the tenant at request time; nothing is stored, estimated or rounded. `legalEntityId` narrows it to one legal entity.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)legalEntityId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/reports/in-transit' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/reports/receivables tenantReportsGetReceivables

Human Supabase USER only; permissions sales.read, customers.read. Read-only report computed from the ledgers and documents of the tenant at request time; nothing is stored, estimated or rounded. `legalEntityId` narrows it to one legal entity.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)legalEntityId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/reports/receivables' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/reports/payables tenantReportsGetPayables

Human Supabase USER only; permissions purchases.read. Read-only report computed from the ledgers and documents of the tenant at request time; nothing is stored, estimated or rounded. `legalEntityId` narrows it to one legal entity.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)limit (query)cursor (query)legalEntityId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/reports/payables' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta

Accounting

GET /tenants/{tenantId}/accounting/payment-options tenantAccountingGetPaymentOptions

Human Supabase USER only; permissions payments.accounts.read, an operational duty of whoever collects or pays. It lists the active money accounts of one entity that fit each method, the one preselected and what a till movement may be booked against. It carries no balance, mapping, entry or configuration, and accounting.read is not needed. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)legalEntityId* (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/payment-options?legalEntityId=<legalEntityId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/accounting/ledgers tenantAccountingGetLedgers

Human Supabase USER only; permissions accounting.read. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/ledgers' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/accounting/ledgers tenantAccountingPostLedgers

Human Supabase USER only; permissions accounting.configure. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/ledgers' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/accounting/ledgers/{id} tenantAccountingPutLedgersById

Human Supabase USER only; permissions accounting.configure. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/ledgers/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/accounting/accounts tenantAccountingGetAccounts

Human Supabase USER only; permissions accounting.read. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)legalEntityId* (query)status (query)type (query)kind (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/accounts?legalEntityId=<legalEntityId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/accounting/accounts tenantAccountingPostAccounts

Human Supabase USER only; permissions accounting.configure. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/accounts' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/accounting/accounts/{id} tenantAccountingPutAccountsById

Human Supabase USER only; permissions accounting.configure. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/accounts/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/accounting/mappings tenantAccountingGetMappings

Human Supabase USER only; permissions accounting.read. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)legalEntityId* (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/mappings?legalEntityId=<legalEntityId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/accounting/mappings tenantAccountingPutMappings

Human Supabase USER only; permissions accounting.configure. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/mappings' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/accounting/fiscal-years tenantAccountingGetFiscalYears

Human Supabase USER only; permissions accounting.read. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)legalEntityId* (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/fiscal-years?legalEntityId=<legalEntityId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/accounting/fiscal-years tenantAccountingPostFiscalYears

Human Supabase USER only; permissions accounting.configure. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/fiscal-years' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/accounting/fiscal-years/{id}/close tenantAccountingPostFiscalYearsByIdClose

Human Supabase USER only; permissions accounting.close. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/fiscal-years/{id}/close' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/accounting/periods/{id}/close tenantAccountingPostPeriodsByIdClose

Human Supabase USER only; permissions accounting.close. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/periods/{id}/close' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/accounting/periods/{id}/reopen tenantAccountingPostPeriodsByIdReopen

Human Supabase USER only; permissions accounting.close. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/periods/{id}/reopen' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/accounting/entries tenantAccountingGetEntries

Human Supabase USER only; permissions accounting.read. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)legalEntityId* (query)limit (query)cursor (query)status (query)from (query)to (query)sourceId (query)accountId (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/entries?legalEntityId=<legalEntityId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/accounting/entries tenantAccountingPostEntries

Human Supabase USER only; permissions accounting.post. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/entries' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/accounting/entries/{id} tenantAccountingGetEntriesById

Human Supabase USER only; permissions accounting.read. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/entries/{id}' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/accounting/entries/{id}/post tenantAccountingPostEntriesByIdPost

Human Supabase USER only; permissions accounting.approve; never the user who prepared the entry. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/entries/{id}/post' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/accounting/entries/{id}/reject tenantAccountingPostEntriesByIdReject

Human Supabase USER only; permissions accounting.approve; never the user who prepared the entry. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/entries/{id}/reject' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/accounting/entries/{id}/reverse tenantAccountingPostEntriesByIdReverse

Human Supabase USER only; permissions accounting.post and accounting.approve. Only manual and opening entries: the entry of an operation is reversed by voiding the operation. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/entries/{id}/reverse' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/accounting/operations/{id}/entries tenantAccountingGetOperationsByIdEntries

Human Supabase USER only; permissions accounting.read. `id` is the operation: an invoice, payment, credit, sales order, counter session or receipt, purchase order or receipt, transfer or import order, supplier return, settlement or inventory movement. Its own entries, those of what hangs from it and their reversals. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/operations/{id}/entries' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/accounting/general-ledger tenantAccountingGetGeneralLedger

Human Supabase USER only; permissions accounting.read. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)legalEntityId* (query)accountId* (query)from (query)to (query)limit (query)cursor (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/general-ledger?legalEntityId=<legalEntityId>&accountId=<accountId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/accounting/trial-balance tenantAccountingGetTrialBalance

Human Supabase USER only; permissions accounting.read. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)legalEntityId* (query)from (query)to (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/trial-balance?legalEntityId=<legalEntityId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/accounting/reconciliation tenantAccountingGetReconciliation

Human Supabase USER only; permissions accounting.read. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)legalEntityId* (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/reconciliation?legalEntityId=<legalEntityId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/accounting/settlements tenantAccountingGetSettlements

Human Supabase USER only; permissions accounting.read. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)legalEntityId* (query)limit (query)cursor (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/settlements?legalEntityId=<legalEntityId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/accounting/settlements tenantAccountingPostSettlements

Human Supabase USER only; permissions accounting.post. Double-entry books per legal entity, in its base currency. Opening a ledger turns accounting on for one legal entity from `startsOn`: from then on every covered operation of that entity (invoices, payments, applications, credits, refunds, counter collections, cash movements, settlements and valued stock movements) writes its entry in the same transaction or does not happen. An entity without a ledger keeps no books and behaves as before. Debits equal credits to the last unit of the currency; amounts are exact and never floats. A posted entry is immutable: it is corrected by a linked mirror entry. One entry per event, enforced by a unique key. A closed period refuses every new entry dated in it. Manual and opening entries are proposals until a different user approves them. Billing, delivery and collection are separate facts: an invoice never recognises revenue by itself, a goods receipt and its bill never count inventory twice, and an application distributes money or credit already booked without bringing money in. Card vouchers and cheques wait in clearing accounts until a settlement records the real net and fee. No tax, fiscal policy, exchange rate or cost is ever invented: what is missing blocks the operation with a specific code. Writes are idempotent, tenant scoped and audited.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/accounting/settlements' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta

Valuation

GET /tenants/{tenantId}/valuation/default tenantValuationGetDefault

Human Supabase USER only; permissions accounting.read. The company keeps a default method (WEIGHTED_AVERAGE, FIFO or BY_PRODUCT): a legal entity inherits it when its books open without stating one, and may state a different one. The effective policy belongs to the entity and, in BY_PRODUCT, to each product; changing the company default never changes a ledger that exists. Inventory valuation per legal entity and variant: moving weighted average or FIFO cost layers. The entity chooses one method, or BY_PRODUCT, where each product chooses before its stock can be valued; variants inherit the product policy and keep independent costs, and every warehouse of the entity shares it. Stock in hand and stock in a transit warehouse are valued apart. Costs come from the purchase order line, from the cost stated on a manual entry of stock, or travel with the stock from the pool it leaves; they are never sale prices, never estimated and never taken as zero. FIFO decides which costs are consumed, not which physical unit or IMEI must be delivered; every serialized movement keeps its unit identity. Values are rounded half up to the minor unit of the currency, and taking everything takes every cent. After valued movements the method changes only through a dated, audited transition that carries the current value over and rewrites nothing. Writes are idempotent and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/valuation/default' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/valuation/default tenantValuationPutDefault

Human Supabase USER only; permissions accounting.configure and settings.manage. Sets the company default: what a legal entity inherits when its books open without stating a method. It is a new version; ledgers that exist keep their method, their valued stock and their entries. The company keeps a default method (WEIGHTED_AVERAGE, FIFO or BY_PRODUCT): a legal entity inherits it when its books open without stating one, and may state a different one. The effective policy belongs to the entity and, in BY_PRODUCT, to each product; changing the company default never changes a ledger that exists. Inventory valuation per legal entity and variant: moving weighted average or FIFO cost layers. The entity chooses one method, or BY_PRODUCT, where each product chooses before its stock can be valued; variants inherit the product policy and keep independent costs, and every warehouse of the entity shares it. Stock in hand and stock in a transit warehouse are valued apart. Costs come from the purchase order line, from the cost stated on a manual entry of stock, or travel with the stock from the pool it leaves; they are never sale prices, never estimated and never taken as zero. FIFO decides which costs are consumed, not which physical unit or IMEI must be delivered; every serialized movement keeps its unit identity. Values are rounded half up to the minor unit of the currency, and taking everything takes every cent. After valued movements the method changes only through a dated, audited transition that carries the current value over and rewrites nothing. Writes are idempotent and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/valuation/default' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/valuation/cost-adjustments tenantValuationGetCostAdjustments

Human Supabase USER only; permissions accounting.read. A purchase cost corrected after the goods were received, by a supplier credit whose reason is COST_CORRECTION or by matching a supplier bill with its receipt lines. No other credit ever touches inventory. Each correction names receipt lines; for each one the valued history says where those goods are now: what the entity still holds changes value where it is, in stock or in transit, and what already left (sold, lost, returned, sent to another entity) goes to the PURCHASE_COST_VARIANCE account. Under FIFO the layers of the receipt decide what is still held, which need not be the same physical units or IMEI; under weighted average every exit took its proportion of the pool. Nothing is recalculated backwards and no posted entry is rewritten: an adjustment is a new dated event with one ledger entry, and it is undone by another adjustment that names it. A receipt line is matched with one bill line at a time, a credit adjusts once, and a correction never leaves goods with a negative cost. Receipts older than the ledger have no cost in it: 409 COST_SOURCE_NOT_VALUED.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)legalEntityId* (query)sourceId (query)cursor (query)limit (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/valuation/cost-adjustments?legalEntityId=<legalEntityId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/orders/{id}/received-lines tenantPurchasesGetOrdersByIdReceivedLines

Human Supabase USER only; permissions purchases.read. A purchase cost corrected after the goods were received, by a supplier credit whose reason is COST_CORRECTION or by matching a supplier bill with its receipt lines. No other credit ever touches inventory. Each correction names receipt lines; for each one the valued history says where those goods are now: what the entity still holds changes value where it is, in stock or in transit, and what already left (sold, lost, returned, sent to another entity) goes to the PURCHASE_COST_VARIANCE account. Under FIFO the layers of the receipt decide what is still held, which need not be the same physical units or IMEI; under weighted average every exit took its proportion of the pool. Nothing is recalculated backwards and no posted entry is rewritten: an adjustment is a new dated event with one ledger entry, and it is undone by another adjustment that names it. A receipt line is matched with one bill line at a time, a credit adjusts once, and a correction never leaves goods with a negative cost. Receipts older than the ledger have no cost in it: 409 COST_SOURCE_NOT_VALUED.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/orders/{id}/received-lines' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/purchases/bills/{id}/receipt-matching tenantPurchasesGetBillsByIdReceiptMatching

Human Supabase USER only; permissions purchases.read. A purchase cost corrected after the goods were received, by a supplier credit whose reason is COST_CORRECTION or by matching a supplier bill with its receipt lines. No other credit ever touches inventory. Each correction names receipt lines; for each one the valued history says where those goods are now: what the entity still holds changes value where it is, in stock or in transit, and what already left (sold, lost, returned, sent to another entity) goes to the PURCHASE_COST_VARIANCE account. Under FIFO the layers of the receipt decide what is still held, which need not be the same physical units or IMEI; under weighted average every exit took its proportion of the pool. Nothing is recalculated backwards and no posted entry is rewritten: an adjustment is a new dated event with one ledger entry, and it is undone by another adjustment that names it. A receipt line is matched with one bill line at a time, a credit adjusts once, and a correction never leaves goods with a negative cost. Receipts older than the ledger have no cost in it: 409 COST_SOURCE_NOT_VALUED.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/bills/{id}/receipt-matching' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/bills/{id}/receipt-matches tenantPurchasesPostBillsByIdReceiptMatches

Human Supabase USER only; permissions purchases.approve. States which receipt lines each line of an issued bill invoices; equal amounts are matched and post nothing, a different amount becomes a cost adjustment against the purchase bridge. A purchase cost corrected after the goods were received, by a supplier credit whose reason is COST_CORRECTION or by matching a supplier bill with its receipt lines. No other credit ever touches inventory. Each correction names receipt lines; for each one the valued history says where those goods are now: what the entity still holds changes value where it is, in stock or in transit, and what already left (sold, lost, returned, sent to another entity) goes to the PURCHASE_COST_VARIANCE account. Under FIFO the layers of the receipt decide what is still held, which need not be the same physical units or IMEI; under weighted average every exit took its proportion of the pool. Nothing is recalculated backwards and no posted entry is rewritten: an adjustment is a new dated event with one ledger entry, and it is undone by another adjustment that names it. A receipt line is matched with one bill line at a time, a credit adjusts once, and a correction never leaves goods with a negative cost. Receipts older than the ledger have no cost in it: 409 COST_SOURCE_NOT_VALUED.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/bills/{id}/receipt-matches' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/purchases/bills/{id}/receipt-matches/{adjustmentId}/reverse tenantPurchasesPostBillsByIdReceiptMatchesByAdjustmentIdReverse

Human Supabase USER only; permissions purchases.approve. Undoes one matching with its opposite adjustment, distributed as the goods stand today, and frees its receipt lines. A matched bill cannot be voided before this. A purchase cost corrected after the goods were received, by a supplier credit whose reason is COST_CORRECTION or by matching a supplier bill with its receipt lines. No other credit ever touches inventory. Each correction names receipt lines; for each one the valued history says where those goods are now: what the entity still holds changes value where it is, in stock or in transit, and what already left (sold, lost, returned, sent to another entity) goes to the PURCHASE_COST_VARIANCE account. Under FIFO the layers of the receipt decide what is still held, which need not be the same physical units or IMEI; under weighted average every exit took its proportion of the pool. Nothing is recalculated backwards and no posted entry is rewritten: an adjustment is a new dated event with one ledger entry, and it is undone by another adjustment that names it. A receipt line is matched with one bill line at a time, a credit adjusts once, and a correction never leaves goods with a negative cost. Receipts older than the ledger have no cost in it: 409 COST_SOURCE_NOT_VALUED.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)id* (path)adjustmentId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/purchases/bills/{id}/receipt-matches/{adjustmentId}/reverse' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/valuation/pools tenantValuationGetPools

Human Supabase USER only; permissions accounting.read. The company keeps a default method (WEIGHTED_AVERAGE, FIFO or BY_PRODUCT): a legal entity inherits it when its books open without stating one, and may state a different one. The effective policy belongs to the entity and, in BY_PRODUCT, to each product; changing the company default never changes a ledger that exists. Inventory valuation per legal entity and variant: moving weighted average or FIFO cost layers. The entity chooses one method, or BY_PRODUCT, where each product chooses before its stock can be valued; variants inherit the product policy and keep independent costs, and every warehouse of the entity shares it. Stock in hand and stock in a transit warehouse are valued apart. Costs come from the purchase order line, from the cost stated on a manual entry of stock, or travel with the stock from the pool it leaves; they are never sale prices, never estimated and never taken as zero. FIFO decides which costs are consumed, not which physical unit or IMEI must be delivered; every serialized movement keeps its unit identity. Values are rounded half up to the minor unit of the currency, and taking everything takes every cent. After valued movements the method changes only through a dated, audited transition that carries the current value over and rewrites nothing. Writes are idempotent and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)legalEntityId* (query)variantId (query)limit (query)cursor (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/valuation/pools?legalEntityId=<legalEntityId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/valuation/entries tenantValuationGetEntries

Human Supabase USER only; permissions accounting.read. The company keeps a default method (WEIGHTED_AVERAGE, FIFO or BY_PRODUCT): a legal entity inherits it when its books open without stating one, and may state a different one. The effective policy belongs to the entity and, in BY_PRODUCT, to each product; changing the company default never changes a ledger that exists. Inventory valuation per legal entity and variant: moving weighted average or FIFO cost layers. The entity chooses one method, or BY_PRODUCT, where each product chooses before its stock can be valued; variants inherit the product policy and keep independent costs, and every warehouse of the entity shares it. Stock in hand and stock in a transit warehouse are valued apart. Costs come from the purchase order line, from the cost stated on a manual entry of stock, or travel with the stock from the pool it leaves; they are never sale prices, never estimated and never taken as zero. FIFO decides which costs are consumed, not which physical unit or IMEI must be delivered; every serialized movement keeps its unit identity. Values are rounded half up to the minor unit of the currency, and taking everything takes every cent. After valued movements the method changes only through a dated, audited transition that carries the current value over and rewrites nothing. Writes are idempotent and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)legalEntityId* (query)variantId* (query)limit (query)cursor (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/valuation/entries?legalEntityId=<legalEntityId>&variantId=<variantId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
GET /tenants/{tenantId}/valuation/policies tenantValuationGetPolicies

Human Supabase USER only; permissions accounting.read and catalog.read. The company keeps a default method (WEIGHTED_AVERAGE, FIFO or BY_PRODUCT): a legal entity inherits it when its books open without stating one, and may state a different one. The effective policy belongs to the entity and, in BY_PRODUCT, to each product; changing the company default never changes a ledger that exists. Inventory valuation per legal entity and variant: moving weighted average or FIFO cost layers. The entity chooses one method, or BY_PRODUCT, where each product chooses before its stock can be valued; variants inherit the product policy and keep independent costs, and every warehouse of the entity shares it. Stock in hand and stock in a transit warehouse are valued apart. Costs come from the purchase order line, from the cost stated on a manual entry of stock, or travel with the stock from the pool it leaves; they are never sale prices, never estimated and never taken as zero. FIFO decides which costs are consumed, not which physical unit or IMEI must be delivered; every serialized movement keeps its unit identity. Values are rounded half up to the minor unit of the currency, and taking everything takes every cent. After valued movements the method changes only through a dated, audited transition that carries the current value over and rewrites nothing. Writes are idempotent and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)legalEntityId* (query)limit (query)cursor (query)
Respuestas
200400401403404409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/valuation/policies?legalEntityId=<legalEntityId>' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
PUT /tenants/{tenantId}/valuation/policies tenantValuationPutPolicies

Human Supabase USER only; permissions accounting.configure. Only while the entity values BY_PRODUCT and the product has no valued movement. The company keeps a default method (WEIGHTED_AVERAGE, FIFO or BY_PRODUCT): a legal entity inherits it when its books open without stating one, and may state a different one. The effective policy belongs to the entity and, in BY_PRODUCT, to each product; changing the company default never changes a ledger that exists. Inventory valuation per legal entity and variant: moving weighted average or FIFO cost layers. The entity chooses one method, or BY_PRODUCT, where each product chooses before its stock can be valued; variants inherit the product policy and keep independent costs, and every warehouse of the entity shares it. Stock in hand and stock in a transit warehouse are valued apart. Costs come from the purchase order line, from the cost stated on a manual entry of stock, or travel with the stock from the pool it leaves; they are never sale prices, never estimated and never taken as zero. FIFO decides which costs are consumed, not which physical unit or IMEI must be delivered; every serialized movement keeps its unit identity. Values are rounded half up to the minor unit of the currency, and taking everything takes every cent. After valued movements the method changes only through a dated, audited transition that carries the current value over and rewrites nothing. Writes are idempotent and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
200400401403404409429503 
curl --request PUT \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/valuation/policies' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/valuation/transitions tenantValuationPostTransitions

Human Supabase USER only; permissions accounting.configure and accounting.approve. The company keeps a default method (WEIGHTED_AVERAGE, FIFO or BY_PRODUCT): a legal entity inherits it when its books open without stating one, and may state a different one. The effective policy belongs to the entity and, in BY_PRODUCT, to each product; changing the company default never changes a ledger that exists. Inventory valuation per legal entity and variant: moving weighted average or FIFO cost layers. The entity chooses one method, or BY_PRODUCT, where each product chooses before its stock can be valued; variants inherit the product policy and keep independent costs, and every warehouse of the entity shares it. Stock in hand and stock in a transit warehouse are valued apart. Costs come from the purchase order line, from the cost stated on a manual entry of stock, or travel with the stock from the pool it leaves; they are never sale prices, never estimated and never taken as zero. FIFO decides which costs are consumed, not which physical unit or IMEI must be delivered; every serialized movement keeps its unit identity. Values are rounded half up to the minor unit of the currency, and taking everything takes every cent. After valued movements the method changes only through a dated, audited transition that carries the current value over and rewrites nothing. Writes are idempotent and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/valuation/transitions' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta
POST /tenants/{tenantId}/valuation/opening-balances tenantValuationPostOpeningBalances

Human Supabase USER only; permissions accounting.configure and accounting.post. Values, at the stated cost, the stock the entity already held and that has no value yet; 409 when nothing is left to value. The company keeps a default method (WEIGHTED_AVERAGE, FIFO or BY_PRODUCT): a legal entity inherits it when its books open without stating one, and may state a different one. The effective policy belongs to the entity and, in BY_PRODUCT, to each product; changing the company default never changes a ledger that exists. Inventory valuation per legal entity and variant: moving weighted average or FIFO cost layers. The entity chooses one method, or BY_PRODUCT, where each product chooses before its stock can be valued; variants inherit the product policy and keep independent costs, and every warehouse of the entity shares it. Stock in hand and stock in a transit warehouse are valued apart. Costs come from the purchase order line, from the cost stated on a manual entry of stock, or travel with the stock from the pool it leaves; they are never sale prices, never estimated and never taken as zero. FIFO decides which costs are consumed, not which physical unit or IMEI must be delivered; every serialized movement keeps its unit identity. Values are rounded half up to the minor unit of the currency, and taking everything takes every cent. After valued movements the method changes only through a dated, audited transition that carries the current value over and rewrites nothing. Writes are idempotent and tenant scoped.

Autenticación
SupabaseBearer · http bearer
Parámetros
tenantId* (path)Idempotency-Key* (header)
Respuestas
201400401403404409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/tenants/{tenantId}/valuation/opening-balances' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta

Onboarding

GET /onboarding onboardingState

Active human identity only. Own immutable completion receipt and server-owned setup/plan options. No business access or global grants from signup.

Autenticación
SupabaseBearer · http bearer
Respuestas
200400401403409429503 
curl --request GET \
  --url 'https://api.marky.ec/v1/onboarding' \
  --header 'Authorization: Bearer <SupabaseBearer>'
Ver parámetros, cuerpo y esquemas de respuesta
POST /onboarding completeOnboarding

Deliberate atomic creation of the account’s first self-service tenant, its local administrator, entity, branch, warehouse, internal list, empty ledger and selected fiscal year. Opening date must be within a fiscal range of at most 366 days; clipped monthly periods cover it exactly. User-bound durable idempotency: same key+input replays; changed input or another key after creation returns 409. Paid selection is PENDING_PAYMENT with FREE entitlements until verified activation; no payment is collected. No caller-supplied identity, IDs, roles, price or entitlement. Other memberships and legacy companies are unchanged.

Autenticación
SupabaseBearer · http bearer
Parámetros
Idempotency-Key* (header)
Respuestas
201400401403409429503 
curl --request POST \
  --url 'https://api.marky.ec/v1/onboarding' \
  --header 'Authorization: Bearer <SupabaseBearer>' \
  --header 'Idempotency-Key: <Idempotency-Key>' \
  --header 'Content-Type: application/json' \
  --data @body.json
Ver parámetros, cuerpo y esquemas de respuesta