Changelog

This changelog tracks backend-relevant changes that are now reflected in the Fangate developer documentation.

It is organized by confirmed implementation areas rather than guessed release names where exact release labeling was not available.

2026-10-31 - Agency share from 0 %

Changed

• revenue_share_percent accepts 0 (was 1 to 100) on POST /api/agencies/me/creators/invite and on PATCH /api/agencies/me/creators/{link}/share: an agency can work without a share, and the creator then keeps the whole earning. Lowering the share still applies at once, and changing it still needs an active relationship. See Agency accounts.

2026-10-31 - A creator's accept as a webhook

Added

• agency.relationship_accepted: a creator accepted the agency's invitation and the relationship is active. Sent to the agency's and the creator's own webhooks that subscribe to it. data: agency_link_id, agency_account_id, creator_account_id, creator_account_key (the conn_ key to send as X-Fangate-Account for this creator from now on), creator_name, accepted_at. Until now an integration learned of a new creator only by listing GET /api/agencies/me/accounts again. See Webhooks.

2026-10-29 - Product lists read the product itself

Changed

• GET /api/products and GET /api/products/collection take media_duration_seconds, thumbnail_url and trailer_url from the product itself: its own first file and its own preview assets. Before, a product without one of them showed the value of another product of yours holding the same file, which made a page of 50 products take up to 13 seconds for a large vault. A product still shows its own duration, thumbnail and trailer as before. See Products.

2026-10-29 - Your own reference per link

Docs

• link_reference in the payment webhooks is documented: a reference of your own on the sales link (?ref=), on the Telegram link (--<reference>) or on the crm: card query (#<reference>) comes back with the sale, null without one. Every payment method of the checkout page keeps it; before this release only PayPal purchases did. See Your own reference per link and Delivery payload.
• A retry after a declined payment keeps it: the failure return sends the fan back to the product page with ?ref= again, so the second attempt carries the same reference as the first.

2026-10-29 - Tips up to 300.00

Changed

• The platform's tip range is now 5.00 to 300.00 (was 5.00 to 150.00): tip_limits.max_cents reads 30000, and min_tip_cents - on the account and on a product - may go up to that. See Users and Products.

2026-10-21 - Telegram card as a photo

Docs

• GET /api/products/{product}/telegram-card is documented: Fangate's card picture for the product's Telegram card (the locked preview with the lock and one line burned in) and the button text with the price the fan pays, for a bot of your own that sends the card as a photo. Readable with api-key:urls.read; new error code card_picture_unavailable (409). See Products and Error codes.
• The inline query crm:<product id>:<key> [caption] sends the card picture as a photo from the creator's own account, marked "via" Fangate's bot; key comes from the endpoint above. See From the creator's own Telegram account.
• Posting a product card now shows the card as a photo next to the link preview, and names Telegram's rule that only bots attach buttons: from the creator's own account the card goes out as a bot's inline result marked "via @<bot>", or without that mark through your bot as the account's Telegram Business chatbot.

2026-10-14 - Minimum payout

Changed

• POST /api/wallet/cashout refuses requests below 30.00 in the wallet's currency with the new error code payout_below_minimum (422). Fangate's own app enforced this at the button only; the endpoint now does too. The minimum itself goes through; an empty wallet still answers 400 "No available funds". GET /api/wallet carries the new field payout_minimum (cents), and cashout_available is false below it, on the wallet and on every entry of balances[]. See Wallet and Error codes.

2026-10-13 - Payment limits per price

Docs

• Products now names the payment limits: PayPal up to a price of 250.00 USD / 224.00 EUR, card payments up to 440.00 USD / 395.00 EUR / 200.00 GBP, crypto above that. Fangate's own app accepts prices up to the card limits. The API itself still sets no upper limit on price.

2026-10-12 - AI models for creators

Added

• A creator opens AI models of its own, the way an agency does: GET / POST /api/user/ai-models, PATCH / DELETE /api/user/ai-models/{model}, and the dashboard session POST /api/user/ai-models/{model}/session. A model sells fully AI-generated content only, in the creator's currency; everything it earns is booked to the creator's wallet and counts as the creator's sale. can_manage_ai_models is open to a creator's key, and X-Fangate-Account: aim_<id> runs a call as one of the creator's models. The creator's own webhooks hear the model's events with an account block. New error code ai_model_owner_verification_required. See AI models of a creator.

2026-10-11 - Registration from your own screens published, partner integration notes

Docs

• Onboarding now describes the whole registration as partners run it from screens of their own: the confirmation click and GET /api/registration/email-status, the embedded signature form and GET /api/registration/signature-status, return_url on the confirmation mail, the login token and the key created right after, and the order of calls for a new creator. Auth, Authentication, App data, Error codes (email_not_confirmed) and Vault for integrations carry the matching details again.
• New page Partner integration notes: where a CRM or vault starts in this documentation and what we need from you to register your servers and pages.

2026-10-10 - Products taken off sale by Fangate

Added

• purchase_block_code: removed_by_fangate and the owner-only product field removed_by_fangate: Fangate has taken the whole product off sale - no new purchases, no Explore card - while its files are untouched and buyers who already bought keep their access. Neither sales_stopped: false nor sales_end_at: null lifts it. Subscribers of product.blocked receive it with reason: manually_rejected when the product was sellable at that moment. See Error codes.

2026-10-09 - Webhooks per file: media.approved and media.rejected

Added

• media.approved / media.rejected outbound webhook events: the moderation verdict of one file, sent when its status becomes final - by the automated check or the Fangate team. data carries media_id, product_id (null for a vault file), client_reference, product_ids (every product the file hangs in), status and, on a rejection, reason (automatically_rejected_manual_review, which the manual review may overturn, or manually_rejected). Verdicts, not sellability: product.sellable and product.blocked keep speaking for the product. Opt in on POST / PATCH /api/webhooks. See File verdicts.

Changed

• Retry schedule for media.*: 5 attempts (1 min, 5 min, 30 min, 2 h), done about 2.5 hours after the first; all other events keep the 7 attempts up to 24 h. A redelivery runs the schedule of its event.
• A delivery queued from inside a database transaction is now dispatched after the commit - a status written during a consent approval could leave its delivery pending for good.

2026-10-08 - Crypto payouts, verification state for agency API keys, payout details at registration

Added

• Crypto payouts: payout_method (wire | crypto) and tron_usdt_wallet on GET / PATCH /api/user - a payout goes either to the bank account or as USDT to a TRON (TRC-20) wallet; both sets stay stored. The crypto rail carries its own withdrawal fee; the USDT amount sent is the payout minus the withdrawal fee and any bank conversion fee at the rate of the day, and the payout confirmation names it. See Payout account.
• GET /api/agencies/me/verification: why an agency is still pending - kyb_status, missing_documents, document_requests, blocked_reason - open to every API key of the agency, read-only. The full record under GET /api/agencies/me stays closed to keys. See Agency accounts.
• Registration: POST /api/register and POST /api/agencies/register take payout_method and tron_usdt_wallet next to bank_data; an agency registers as entity_kind: company (with elf_code) or sole_proprietor (bank statement only for the review). Fangate's own creator registration offers the payout account again as an optional, collapsed tile on the currency step; GBP is no longer offered to new accounts.
• vat_number on GET / PATCH /api/user: the creator's VAT number, stored only after the EU VAT register (VIES) confirms it.
• crypto_payouts_enabled on GET /api/app-data: whether crypto payouts can be chosen yet. While false, payout_method: crypto on POST /api/register, POST /api/agencies/register and PATCH /api/user answers 422 validation_failed; an account that already pays out by crypto is not affected.
• USDT estimate for crypto payouts: GET /api/wallet carries crypto_estimate (top level and per entry of balances[]: usdt, rate and the deducted fees in cents) - what the available balance is expected to buy in USDT after fees, at the rate of the day; null unless the account pays out by crypto and a rate is known. Rows with booking_kind: payout_requested carry usdt_estimate the same way; the payout confirmation names what was actually sent.
• country_code on POST /api/register and GET / PATCH /api/user: the creator's country of residence (ISO 3166-1 alpha-2), the basis for the VAT on Fangate's commission.

2026-10-06 - Agency relationship end as a webhook

Added

• agency.relationship_ended webhook event: an agency integration (and the creator's own) learns within seconds that a creator left or was dropped, and can lock that creator's data on its side. Payload: agency_link_id, agency_account_id, creator_account_id, creator_account_key, ended_at, ended_by. See Webhooks.

2026-10-02 - Model accounts for agencies

Added

• Model accounts: an agency registers a real person who signed a release with it, files the release form and the ID (or asks the person to fill in Fangate's form), and sells in the account once Fangate approved the file - GET / POST / PATCH / DELETE /api/agencies/me/models, documents under /documents, a fresh link for the model under /resend-link. Every upload is tagged with the model automatically; the model keeps a page of her own to withdraw consent per product or for everything. Open to the agency's login token and to API keys with can_manage_ai_models. See Model accounts.
• GET /api/agencies/me/accounts lists a model account with kind: model_showroom; agency-wide webhook deliveries carry the same kind in their account block, and the scope agency_scope_ai_models hears model accounts as well.
• Error codes model_email_taken, model_release_pending, model_link_expired, model_login_failed, model_session_scope - see Error codes.

Docs

• Agency accounts: new section Model accounts; the API-key and webhook notes name model accounts beside AI models.

2026-09-29 - Wallet list: bookings, filters and paging

Added

• GET /api/wallet takes currency (list the rows of another currency balance), bookings=1 (one row per booking, without hold and release rows), activity (earnings, refunds, payouts, affiliate) and sort (newest, oldest, largest). All optional; without them the list is unchanged.
• Every transaction row carries booking_kind, and earnings hold_status / hold_until; agency share rows name the selling creator in counterparty.
• transactions_meta (current_page, last_page, per_page, total) next to transactions.

Docs

• Wallet: new parameters and fields; transactions is shown as the array it is.

2026-09-28 - Display consent optional in production

Changed

• content_display_consent is optional again in production (GET /api/app-data → registration.content_display_consent.required: false). A POST /api/register without the field is accepted; the consent is then not recorded. Registration screens should still show the checkbox and send content_display_consent: true once the creator ticks it. Sent as false, the field is still refused with content_display_consent_required.

Docs

• Auth and Onboarding: the consent is recommended, not required.

2026-09-28 - Display consent required in production

Changed

• content_display_consent is required in production since the evening of 2026-09-27 (GET /api/app-data → registration.content_display_consent.required: true). A POST /api/register without content_display_consent: true answers 422 with errors_code: content_display_consent_required.

Fixed

• errors_code on POST /api/register: content_display_consent_required was also returned when another field failed first (for example a missing first_name), so code and message named different fields. The code now belongs to the first failure, like every other coded refusal.

Docs

• Auth and Onboarding: the consent is required; payout details and the address are not asked at sign-up.

2026-09-27 - Display consent at registration, payout account and recipient

Added

• content_display_consent on POST /api/register: the creator's consent to the public display of their content, a checkbox of its own next to the legal acceptance (card-scheme requirement). Wording and whether it is required come from GET /api/app-data → registration.content_display_consent; required once the admin switch is on, and refused with content_display_consent_required when sent as false. Stored with timestamp and wording; existing accounts count as consented on the date they accepted the terms.
• payout_recipient on GET /api/user: who a payout is made out to - the company's legal name, or the name on the verified ID. Derived, never entered.
• payout_account_required (422) on POST /api/wallet/cashout without a saved payout account.

Changed

• Payout account type for every currency: bank_account_types[] no longer ties the US routing number to USD or the UK sort code to GBP. A EUR or GBP balance paid to a US routing number (or EUR to a UK sort code) travels on the SWIFT rail, whose withdrawal_fees[] label is now "International (SWIFT)".
• Registration without bank details: Fangate's own registration no longer collects bank_data; the field stays accepted. The creator adds the payout account before the first cashout.

Docs

• Auth, App data, Users, Wallet, Wallet & Payouts, Error codes.

2026-09-25 - Registration from your own screens

Changed

• The confirmation mail has to be opened before an account can be registered: once switched on, POST /api/register answers 422 email_not_confirmed for an address whose link was never clicked. The Fangate web app and app have always required the click; the rule then holds for every client. See Onboarding.
• Rate limits on the registration helpers: POST /api/user/email/verify 3 a minute per address and 10 per IP; GET /api/registration/signature-status and the new GET /api/registration/email-status 30 a minute per address and 300 per IP (registered partner servers 100 / 600).

Added

• GET /api/registration/email-status?email=: whether the confirmation mail was opened (confirmed) or is older than 48 hours (expired). Public, like the signature status. A confirmation mail and its click are valid for 48 hours; once expired, a new mail starts a fresh 48 hours.
• return_url on POST /api/user/email/verify: the click on the mailed link lands on a page of yours (with ?email=…&email_confirmed=1), on a domain registered with Fangate. See Onboarding.

Docs

• Auth brought up to date with the registration as it is: registration_legal_accepted, agency_invite_token, invite_code and return_url on the confirmation mail, the signature step, JSON example, limits. App data now describes registration.signature and registration.legal; the API key matrix lists the Veriff calls; Webhooks say that a creator's webhook hears one account and which fields the non-payment events carry.

2026-09-25 - Identity verification for programs

Added

• Webhook events account.verified and account.verification_declined: hear when a connected account passes its identity check or Veriff turns a session down. See Webhooks.
• POST /api/veriff/decision and GET /api/veriff/create for API keys: read the verification state, and open a new Veriff session for a creator after a declined, expired or abandoned one (Manage content). A session under review is never replaced (409 verification_pending). See Verification.

2026-09-25 - Higher IP ceilings for agency programs and registered servers

Changed

• Agency programs: the ceiling per IP across all accounts is now 1000 / 1000 / 500 a minute (media reads, product reads, wallet and analytics), up from 600 / 600 / 300. The limits per account are unchanged.

Added

• Registered servers: software that runs many creators' or agencies' keys from a few fixed servers can have those addresses registered; generated keys calling from there are counted on a ceiling of 1000 / 1000 / 500 a minute per IP - the agency program ceiling - instead of the regular one, for creator and agency keys alike. x-ratelimit carries it as ip_ceiling_registered_servers. See Rate limits and Running many accounts from your own servers - also on opening the Fangate dashboard from your own product.

2026-09-27 - a product needs min. 15 characters of text (announced)

Announced

• errors_code: product_text_too_short on POST /api/products, PATCH /api/products/{product} and POST /api/products/{product}/price-links from 27 September 2026: a product needs min. 15 characters in title or public_description (either one; spaces at the ends do not count). Until then nothing changes. Existing products stay as they are; a call that only attaches a further file (product_id) or changes neither text is never refused for this. Send a title or a description of that length today and you will not notice the switch. Details: POST /api/products, error codes.

2026-09-23 Rate limits in the OpenAPI file, link preview

Added

• buyer_price on the product: what the buyer pays at checkout, the number Fangate's Telegram card and the link preview show - and a guide to posting the same card from your own Telegram bot.
• x-ratelimit on every operation with a limit of its own in the OpenAPI file - limit, period, what it is counted per, IP ceiling. See Error handling.
• GET /api/agencies/me/accounts also returns agency (id, name), so an API key can confirm which agency it belongs to. See Agency accounts.

Changed

• Link previews of a sales link show the price the buyer pays (price plus buyer fee, as on the Telegram card) in the title - with the stage name when the product shows it on its item page (show_creator_name), otherwise FANGATE. The large image stays.

2026-09-23 Refund requests

Changed

• A payout no longer sends payment.successful. Until now every paid-out withdrawal of an account went to its payment webhooks as a successful payment with seller_earning 0 and no product. A receiver that counted those as sales can drop them; wallet rows of a payout carry no transaction_id and no sale.

Added

• POST /api/transactions/{transaction_id}/refund-request: ask Fangate to refund a paid sale, up to 30 days after it, once per sale (API keys with Manage content). A granted request ends as payment.cancelled, a refused one sends the new webhook event refund_request.rejected. See Wallet.

2026-09-23 A sale in three numbers

Added

• gross, fees (and their _minor twins) in payment webhooks next to seller_earning: what the buyer paid, every fee in one sum, and the net. gross = fees + seller_earning. See Webhooks.
• buyer_telegram_id in payment webhooks for purchases through the Telegram Mini App (null otherwise).
• sale on wallet rows (gross, fees, net, currency); null for rows without a sale and for affiliate commissions. See Wallet.
• Wallet rows carry client_reference and, in sale, whether the sale still stands: status (paid / reversed), reversed_at, reversal_reason.
• GET /api/fees/preview?price=: net, gross and fees for a price before any sale, with and without the age check. See Wallet.

2026-09-23 AI model names are free

Changed

• An AI model's name no longer has to be unique: POST and PATCH /api/agencies/me/ai-models accept a name another model or a creator already carries (before: 422). A new model's profile address is ten random lower-case letters and digits instead of a form of its name, and a rename no longer changes it. Models created before keep their address. See AI models.
• Deactivating an AI model frees every profile address it used; its name stays. Its product links stay offline.

2026-09-23 Take a product off sale

Changed

• DELETE /api/products/{product_id} with an API key keeps the files in the vault unless the call sends delete_media=1 (before: deleted unless delete_media=0). delete_media=0 works as before. An integration that relied on files being deleted by default must now send delete_media=1. See Products.

Added

• sales_stopped and sales_end_at on PATCH /api/products/{product_id}: take a product off sale at once or from a future moment; false / null undo it. New purchases are refused with purchase_block_code: sales_stopped, buyers who already bought keep their access. Each product is switched on its own. Both fields are returned to the owner in the product object. Details: Products.
• product.blocked reason sales_stopped: sent once per stop; for an end date within five minutes of it passing. See Webhooks.

2026-09-23 Webhooks held to single accounts, and a new signing secret without deleting

Added

• account_keys on POST/PATCH /api/webhooks (agency accounts): the webhook hears the listed accounts only; the two scopes follow from the list. Refunds of earlier sales of a listed account still arrive after the relationship ended. Details: Agency-wide webhooks.
• POST /api/webhooks/{id}/secret: a new signing secret, returned once; the old one stops working at once. Webhook and delivery history stay. Details: Webhooks.
• The webhook resource carries account_keys.

Changed

• A generated agency key without access to connected creators can no longer register or change a webhook that hears creators (agency_scope_creators, or a creator in account_keys): 422. Webhooks that exist keep running.
• A key held to a list of accounts manages agency webhooks held to accounts of its list (before: none).
• Revoking an agency's API key - or a key an agency created on a creator's account - switches off the webhooks it registered (not deleted); a creator's own key takes nothing with it. Deliveries still queued for a switched-off webhook are not sent (they can be sent again once it is back on). When a creator deletes their account, their agency relationships end. A webhook registered by a key the agency created on a creator's account now carries the agency mark: it pauses with the creator's API access switch and is switched off when the relationship ends.
• A key held to a list of accounts manages the webhooks it registered, and others only when every account on their list is on its own; redelivery by a key is limited to deliveries of accounts it may reach (404 otherwise). Rotating the secret of a webhook that hears creators needs access to connected creators.
• Direct file upload on POST /api/products (a file in media) is closed to API keys (403): upload through upload sessions and create the product with upload_session_id. Consent documents (files on POST /api/consents/store-or-send) and the old consent e-mail form are closed to API keys as well - tag the creator or invite with tag_invite.
• POST /api/moderation/check is open to API keys with can_create_new_urls: pre-check a title and public description against the word filter before creating a product (before: login tokens only).
• AI models in their own currency: currency (USD, EUR, GBP) on POST /api/agencies/me/ai-models; without it the agency's currency as before. When it differs from the agency's, the agency's share is converted with the conversion buffer of up to 5 %. See AI models.
• Wallet: hold_period_days, converted_earnings and conversion_buffer_percentage are documented, and how shares earned in another currency are converted (reference rate minus a buffer of up to 5 %) - see Wallet.
• At most 15 webhooks per account: registering the next one answers 422 webhook_limit_reached. Several webhooks per account were always possible and stay so; webhooks that exist are not touched.

2026-09-23 API keys held to a list of accounts, and read-only keys

Added

• account_keys on POST /api/user/api-keys (agency accounts): the key works only in the listed accounts - X-Fangate-Account off the list answers 404 agency_account_not_found, the accounts and AI-model lists show the key's accounts only, and the agency's own money views (/api/wallet, /api/dashboard/summary, /api/analytics/*) answer 403 api_key_scope_requires_account unless an account is named. A model the key creates or a creator it invites joins its list; an ended relationship leaves every list. PATCH /api/user/api-keys/{tokenId} changes the list (login token only). Keys without a list reach every account, as before. Such keys cannot register agency-wide webhooks (422); without the header they do not see them and cannot remove or redeliver them (403 api_key_scope_requires_account). PATCH keeps invitations to not-yet-registered addresses the key holds; a declined invitation leaves every list.
• read_only on POST /api/user/api-keys: a key minted without any write ability; every method but GET answers 403 api_key_read_only.
• GET /api/user/api-keys and the create response carry read_only and account_keys.
• Error codes: api_key_read_only, api_key_scope_requires_account, api_key_limit_reached (an agency holds at most 100 keys at once; revoked and expired keys do not count). Details: API keys.

2026-09 every product is AVS+

Changed

• is_adult_content is always true. Every product gets the 18+ confirmation and, for buyers in countries that require one, the age check - also products that were created as "not adult". The field is still accepted on POST / PATCH /api/products and is marked deprecated: its value is ignored, and a false no longer switches is_verif_age off. Nothing to change for an integration that sends it. See Consent and adult content.

2026-09 consent: one standing auto-approve for AI and ordinary files

Changed

• An accepted consent now creates the standing auto-approve relationship whether the file is an AI file or an ordinary one, and that relationship covers later tags on both kinds. Until now an accept on an AI file (ai_origin other than none) created none, and a standing approval never applied to AI files. The tagged person switches it off as before. See Consents.

2026-09 item page: the creator's name next to the header

Added

• show_creator_name on POST /api/products and PATCH /api/products/{product_id} (boolean, off by default): the item page prints Exclusive content from <stage name> instead of Exclusive content. Only a stage name the account chose itself is printed - never the default Creator plus a number. Returned to the product owner in the product object; a price link copies it from its source. See Products.

2026-09 agency API: one key for every account an agency runs

Added

• AI models: accounts of kind ai_model that belong to an agency and sell fully AI-generated content only - GET / POST / PATCH / DELETE /api/agencies/me/ai-models. See Agency accounts.
• The agency's own API key: two permissions for agency accounts, can_manage_ai_models and can_access_connected_creators, and the header X-Fangate-Account that names the account a call works in. GET /api/agencies/me/accounts lists the accounts with their account_key, is_verified, uploads_allowed, api_access_allowed, currency.
• Inviting creators with the API key: POST /api/agencies/me/creators/invite, up to 125 invitations over the life of the agency (403 agency_invitation_limit_reached beyond - support raises it).
• Agency-wide webhooks: agency_scope_ai_models / agency_scope_creators on a webhook of the agency account; deliveries carry a top-level account block.
• The creator's switches: PATCH /api/agency-membership with agency_api_access and agency_may_upload - a creator stops the agency's API access or its uploads without ending the relationship.
• Error codes: agency_account_key_invalid, agency_account_not_found, agency_api_access_revoked, agency_upload_not_allowed, agency_invitation_limit_reached.
• Rate limits for agencies: counted per named account; 600 / 600 / 300 a minute per IP across all accounts.

Changed

• No e-mail addresses of third persons for generated keys: email is null in GET /api/creators/search and in the consent reads; display names no longer fall back to an address. Login tokens are unchanged.
• An unverified account refuses an API key without opening a verification session (422 creator_verification_required with verification: null). A person signing in still gets the session.
• An agency never answers a consent request addressed to a creator - not in a session, not with a key (403). Asking others for consent is unchanged.
• Inside a creator's account an agency changes and removes only its own webhooks (403 for the creator's).
• A blocked agency reaches no account, receives no webhooks and creates nothing by key.

2026-09 integration report: complete OpenAPI document, price floor, report envelope

Follow-up to an integrator's report. Nothing here changes an existing contract except the items under Changed.

Added

• OpenAPI document (/openapi.json, Swagger UI): every live API route is in it now - 113 paths instead of 74. New: the whole vault API (/api/media*), media and product consent tags, consent relationships and permissions, outbound webhooks (with a webhook.delivery schema describing the POST you receive), analytics, product thumbnail/trailer/attach/detach and the login-token-only account routes. POST /api/products documents both content types and every field (media_ids, ai_origin, ai_attested, the consent fields); POST /api/user/api-keys lists can_manage_webhooks; transaction.resource lists product_id and product_title; price carries minimum: 500; throttled endpoints document 429 and its headers.
• errors_code: price_below_minimum on POST /api/products, PATCH /api/products/{product}/price and POST /api/products/{product}/price-links.
• GET /api/app-data: products.min_price_cents (500) and products.manual_price_review_threshold_cents (15000) - read the price floor and the compliance-review threshold instead of hardcoding them.
• errors_code on every JSON error under /api, with a published list: Error codes. Named codes where the API knows the reason (new: api_key_endpoint_not_allowed, api_key_permission_missing, creator_verification_required at the top level), otherwise a fallback for the status (validation_failed, forbidden, not_found, rate_limited ...). Validation failures add errors_field. Additive - messages and status codes are unchanged.
• Payment options for customers: a creator chooses which checkout tiles are shown (paypal, card, crypto), whether the tip button is offered on the product pages, and the smallest tip - account-wide in the dashboard, per product through payment_options on POST / PATCH /api/products (Products), account-wide through GET / PATCH /api/user/payment-options (login token only). Hiding a tile only hides it; at least one stays shown. What each tile offers, including the local payment options behind "Credit Card / Other": Payment providers.
• client_reference on products: your own reference (up to 64 characters), set on POST / PATCH /api/products, returned in the product and as data.client_reference in every webhook payload.
• GET /api/wallet: optional from / to window and transaction_id per sale row - the same txn_… id payment webhooks send, so a lost webhook can be found.
• POST /api/webhooks/{id}/redeliveries: have a delivery sent again, by transaction_id or delivery_id, with its original body and the same X-Fangate-Delivery-Id.
• X-Fangate-Signature-Timestamped: a second signature header (t=…,v1=… over {t}.{body}), fresh on every attempt, so a five-minute tolerance works. X-Fangate-Signature is unchanged.
• Webhook event payment.cancelled: sent once when a sale that had been paid is taken back (refund, chargeback, cancellation by Fangate), with reason and cancellation_fee_minor and the transaction_id of the original sale.
• Webhook event product.sellable: sent once when a product can be bought for the first time, so integrations no longer poll. New products are checked every few seconds in their first minutes. Opt-in: only webhooks that list the event receive it.
• Webhook event product.blocked: the counterpart - sent when a product cannot be sold, with a reason (automatically_rejected_manual_review, manually_rejected, missing_consent) and the purchase_block_code. Once per product and reason; waiting states are not reported. Opt-in as well.
• seller_earning_minor / set_price_minor in the payment webhook payload: the amounts in minor units, next to the unchanged major-unit fields.
• Manual review of videos above 2.5 GB takes at most 24 hours.
• New guide: Agency accounts - the model for selling for several creators: what an agency account can and cannot do, how a relationship runs, the endpoints.
• Docs: where keys are created (dashboard, Settings → API keys), replay protection for webhooks, units of seller_earning versus REST prices, rate-limit headers, the video moderation rules, the wallet transaction fields.

Changed

• POST /api/report answers the standard envelope with data.id instead of an empty object (status code unchanged). Validation failures keep Laravel's plain format.
• Spec fix: upload_session_part_instruction.headers is a plain string map (the generated document carried a bogus schema reference).
• Webhook retries: a failed delivery is retried after 1 min, 5 min, 30 min, 2 h, 6 h and 24 h (7 attempts, about 32.5 hours in total) instead of giving up after a few minutes. Body, signature and X-Fangate-Delivery-Id stay identical on every retry - widen a timestamp window to at least 36 hours and keep seen delivery ids for two days.
• GET /api/maps/autocomplete and GET /api/maps/place-details are rate limited per IP (sign-up helper, not part of the integration surface).
• is_downloadable is honoured on the upload-session flow of POST /api/products. It used to be ignored there, so a product created with true came out view-only until patched. Without the field the account's upload default still applies. If you sent true and relied on a later PATCH, nothing changes for you; if you sent a value you did not mean, send the one you want.
• Removed GET /api/affiliate/revenue (it never answered successfully); GET /api/wallet/affiliate is the affiliate revenue view.
• PATCH /api/user/{user} answers 403 when {user} is not the authenticated account.
• Spec: price and total_earnings of the product resource state their unit (minor units).

2026-09 API keys: AI classification, vault access, wider whitelist

Third-party tools can now run a creator's whole content cycle through a generated API key - vault, AI classification, consent per file, products from vault files. Two new guides: AI content and Vault for integrations.

Added

• ai_origin / ai_attested on POST /api/upload-sessions, POST /api/media (and defaults of POST /api/media/bulk) and POST /api/products (session and file flows): the file's AI classification (none, synthetic, real_person_self, real_person_other) with the uploader's attestation. PATCH /api/media/{media}/ai-origin corrects it afterwards.
• upload_ai_content in the key creation response: follows create_new_urls. Such keys must send the classification for every new file (422, errors_code: ai_origin_required otherwise).
• errors_code - an additive machine-readable field on the error envelope (today: ai_origin_required, ai_attestation_required).
• Whitelist for generated keys: GET /api/products/{product}, GET /api/media/{media}, GET /api/media/{media}/consent-tags, /api/content-folders*, GET /api/analytics/sales-by-country and /top-buyers, consent relationships and permissions.
• Resource fields documented: is_ai_content, ai_label, telegram_link, purchase_block_code, consent_status on products; ai_origin, ai_label, consent{}, thumbnail on media; all list filters of GET /api/media; delete_media on DELETE /api/products/{product}.

Changed

• PATCH /api/consent-tags/{id} (accept, decline, rescind) now requires the content scope (create_new_urls) instead of the read scope: it is a declaration in the creator's name.
• POST /api/products with upload_session_id now honours ai_origin and ai_attested from the request body (they were ignored before); is_downloadable stays ignored on that path. GET /api/media gains ai_classified (false for files that were never classified, which report ai_origin: none).
• PATCH /api/media/{media}/ai-origin answers validation failures in the standard envelope; PATCH /api/media/{media} with a foreign folder answers 422 instead of 500.
• Generated API keys can no longer create, list or revoke keys, set the account password or account-wide flags - creator login tokens only.

Cut-over for existing keys

Keys with create_new_urls created before this release keep uploading without the classification (files count as none) until they are switched over as well; the date will be announced here and is not scheduled yet. Send ai_origin today and nothing changes for you on that date.

2026-09 agency-created integrations end with the agency relationship

Agencies can operate connected creator accounts. An API key or outbound webhook the agency creates on such an account is now tied to that relationship.

Added / changed

• created_by_agency on GET /api/user/api-keys and GET /api/webhooks — null for your own entries, otherwise { id, name, link_id, link_active }.
• Relationship ends → agency-created API keys are deleted, agency-created webhooks are set to is_active: false (kept in the list, deliveries stop). Your own keys and webhooks are untouched.
• The revocation is recorded in the creator's agency activity log.

Client migration

• Integrations built on a key an agency created stop working when the creator ends the relationship. Use a key the creator created, or the agency API (planned), for anything that must survive.
• Treat created_by_agency as an optional field; older clients can ignore it.

See API Keys — Keys created by an agency and Webhooks — GET /api/webhooks.

2026-06 media-level consent workflow

Consent creator tags and the consent-required flag moved from product-only to per-media scope. Product purchase and explore visibility still aggregate across all linked media.

Added / changed

• media.is_should_consent — whether this upload requires a 2257 / creator-tag workflow.
• consent_creator_tags.media_id — each tag/slot belongs to one media row; unique per (media_id, tagged_user_id).
• products.is_should_consent — derived summary (true when any linked media requires consent); kept for backward-compatible API responses.
• Admin → Uploads — consent status column is per media row, not shared across all files on a product.
• Purchase / is_accessible — blocked when any linked media has open or blocking consent.

Client migration

• Read media_id on consent creator tag resources; group tags by media for per-upload UI.
• Do not assume one consent workflow covers every file on a multi-media product.
• Product is_should_consent remains a quick summary flag but is no longer the source of truth for workflow state.

See Consent & adult content — Media-level consent workflow.

---

2026-06 decoupled media library & n:m product linking

Media is a first-class creator library entity. Products reference one or more library items through an n:m product_media pivot instead of owning duplicated media rows per sales link.

Added

• GET / POST / PATCH / DELETE /api/media — library list (status, folder, unlinked filters), create from finalized upload session, update metadata/folder, delete when not linked to products.
• POST /api/media/bulk — start multiple upload sessions in one call; finalize each session then POST /api/media per file.
• POST /api/products/{product}/media / DELETE /api/products/{product}/media/{media} — attach and detach library media on an existing product.
• product_media pivot — one media row can appear on multiple products; legacy media.product_id is kept in sync for backward compatibility.
• POST /api/products — accepts media_ids[] to create a sellable link from existing library items (legacy upload_session_id and multipart upload remain supported).
• upload_defaults on PATCH /api/user/{id} and GET /api/user — account-level presets (is_adult_content, is_downloadable, is_verif_age, default_price, folder_id) for bulk upload and product creation.
• API keys: /api/media* routes use existing api-key:urls.read / api-key:urls.write abilities.

Changed

• Product–media relationship is n:m via product_media (was one-to-many on media.product_id alone).
• POST /api/products/{product}/price-links reuses existing media rows on the new product instead of duplicating storage paths.
• Moderation stays on media rows (veriff_status); purchasability still evaluates linked media per product.

Client migration

• Prefer library-first flows: upload → POST /api/media → create or attach with media_ids[].
• Treat outbound webhook data.media_ids as an array of m_{id} strings — same contract as before, now backed by the pivot.
• Legacy upload_session_id on POST /api/products continues to work as a compatibility shim.

Documentation

• Media Library — new API reference.
• Products — media_ids create/attach flows and n:m semantics.
• Users — upload_defaults schema.

Notes

• Backend ships in Fangate-backend (merged to dev; main via PR #397).
• Regenerate OpenAPI after deploy if you rely on Swagger UI for the new /api/media operations.

---

2026-06 outbound partner webhooks

Third-party integrators can register HTTPS endpoints and receive real-time payment notifications from Fangate.

Added

• POST / GET / PATCH / DELETE /api/webhooks — creator-authenticated CRUD for outbound webhook endpoints (HTTPS URL, event subscriptions, optional include_set_price).
• Events (v1): payment.successful, payment.failed, payment.pending — dispatched asynchronously when transactions.payment_status changes; does not block payment processing.
• Delivery: HMAC-SHA256 (X-Fangate-Signature), idempotency key (X-Fangate-Delivery-Id), up to 3 attempts with backoff 1 min → 5 min → 30 min; per-attempt delivery log in outbound_webhook_deliveries.
• API keys: optional can_manage_webhooks → ability api-key:webhooks.manage for integrator automation.

Documentation

• Webhooks — outbound (integrator) reference.
• Products — media_ids array contract (n:m pivot; see Media Library).

---

2026-05 master / sub-account linked creator accounts

Backend-owned directional account groups for the creator account switcher replace token-only trust for multi-account analytics.

Added / changed

• account_group_members table — persistent master_user_id → child_user_id links (max 10 sub-accounts per linking account; unique per pair; same sub-account may join multiple masters).
• account_group on POST /api/login, POST /api/register, GET /api/user, and POST /api/login/batch — role (standalone | master | sub_account | hybrid), optional master summary for pure sub_account, linked_accounts for accounts that linked others (master / hybrid).
• GET / POST / DELETE /api/user/linked-accounts — list, link (sub-account credentials), and unlink (per master direction).
• POST /api/user/linked-accounts/{childUserId}/session — Sanctum token for switching when the bearer directly linked that sub-account.
• POST /api/dashboard/summary/aggregate — accounts with linked sub-accounts aggregate persisted links only; additional_tokens ignored for them; pure sub_account without own links gets 403 if it sends additional_tokens.

Client migration

• Stop relying on storing multiple passwords/tokens alone to access the “connected set”.
• Use account_group from login and linked-account APIs; call the session endpoint when switching into a linked sub-account.
• Sub-account logins must not expose sibling accounts from another master’s group.
• hybrid accounts may link their own sub-accounts and aggregate only their linked set.

See Account switcher frontend integration.

---

2026-05 account switcher and multi-account dashboard KPIs

Documentation and bundled OpenAPI (docs/public/openapi.json) now cover creator multi-session (account switcher) flows and aggregated dashboard KPIs across multiple bearer tokens.

Added / clarified

• POST /api/login/batch — batch creator login (up to 10 accounts); returns sessions (each with user + token) and per-row failed entries; rate limited (creator-login-batch).
• GET /api/user/sessions / DELETE /api/user/sessions/{tokenId} — list and revoke Sanctum app sessions (api tokens only; integration API keys fangate-api-key:* are excluded).
• GET /api/dashboard/summary — documents extended fields: currency_unified, accounts[], and conditional root wallet_balance (see Wallet).
• POST /api/dashboard/summary/aggregate — merge the same KPI payload across the authenticated creator plus optional additional_tokens (other creators’ api tokens); trust model and multi-currency behavior documented in Wallet.
• Auth and Authentication — batch login, session list/revoke, and multi-account switching guidance for client teams.

Swagger / OpenAPI

• Fangate-backend: run php artisan l5-swagger:generate so /api/documentation includes the new operations after deploy.
• Fangate-docs: copy the generated api-docs.json into docs/public/openapi.json (or use npm run sync-openapi if your pipeline wires it), then rebuild the site so Swagger UI matches.

Notes

• Live changelog: docs.fangate.app/changelog is produced from this file when the Fangate-docs site is built and deployed; merge and run your usual docs release so the new section appears there.
• Backend code for these endpoints ships in Fangate-backend (not only documentation).

2026-05 price editing (creator links)

Documentation now covers explicit creator control over how a price change is applied: update the existing sellable link’s price, or create a new priced link while keeping the original unchanged.

Added / clarified

• PATCH /api/products/{product}/price — update price on the existing product (same short link URL); validation matches product pricing rules (minor units, minimum).
• POST /api/products/{product}/price-links — create a new product row with a new short link and new price; optional overrides for title and descriptions; 201 Created response documented.
• API reference semantics — clarifies that checkout amounts are driven by products.price while public URLs live on short_links, and that the “new link” flow is implemented as a duplicate product with duplicated media rows pointing at the same storage paths (no re-upload).
• Checkout and analytics behavior — documents server-side price revalidation at checkout start, pending sessions keeping a locked price, per-link metrics, and non-retroactive historical stats (per product agreement).
• API keys — permission matrix extended for the two new paths alongside existing product write routes.

Notes

• Backend implementation and OpenAPI annotations ship in Fangate-backend; regenerate Swagger (php artisan l5-swagger:generate) so /api/documentation lists these operations after deploy.

2026-04 backend documentation synchronization

This documentation pass aligns docs.fangate.app with the current live Fangate backend and recent backend changes deployed across development and production.

Added / clarified

• full upload-session documentation for resumable, multipart, and remote-import upload flows
• current product resource fields, including folder state, collection state, downloadability, and epoch-related flags
• content-folder endpoints and creator-side folder assignment workflow
• current wallet and affiliate endpoints, including invitation, invitation code, invited users, and affiliate revenue coverage
• creator-tag / third-party consent flows, including verification-required responses for tagged users
• current Veriff and Yoti endpoint behavior, including endpoints that do not use the standard API response wrapper
• current report, feedback, maps autocomplete, and webhook behavior
• current environment mapping for production and development API / Swagger endpoints

Backend behavior documented from recent changes

• resumable upload-session backend flow is now the preferred content-ingestion path
• legacy direct upload behavior remains supported and can return async 202 responses
• content folder support is live in the backend via:
  • GET /api/content-folders
  • POST /api/content-folders
  • PATCH /api/content-folders/{contentFolder}
  • DELETE /api/content-folders/{contentFolder}
  • PATCH /api/products/{product}/folder
• product deletion now includes explicit cleanup of legacy consent relations
• private/final storage behavior and legacy-upload mirroring are documented to explain current sales-link media availability handling
• production deploy workflow hardening and main-branch checkout expectations are part of the documented release/deployment history

Swagger / OpenAPI alignment work

• API metadata updated for production and development servers
• missing or incomplete docs added for affiliate revenue, consent-tag endpoints, maps autocomplete, report, and Veriff decision flows
• resource schemas updated to better match current backend fields

Earlier documented backend release areas

2026-04-15 release / production rollout areas

Confirmed backend areas represented in documentation:

• upload-session backend for resumable/direct-to-storage uploads
• content folders and product-folder assignment
• media URL/storage resolution fixes across process/final disks
• related web media access and notification changes
• Swagger/OpenAPI coverage improvements for new backend flows

2026-04-04 documentation and platform updates

Previously documented and retained as relevant:

• post-purchase viewer and buyer-access improvements
• creator consent tagging improvements
• manual-approval notification updates

Notes

• This changelog only lists changes that were confirmed from backend code, routes, resources, annotations, and recent git history.
• Where an exact deployment label was unclear, the change is grouped by backend area rather than an invented release number.