Change log
API changes, with the most recent changes first.
POST /invitation: configurable post-processing masks
Change date: October 21, 2026
POST /invitation now accepts config.post_processing_actions to apply masks to the main photo. Supported values are "mask-round-hard", "mask-round-soft", or an array of these values. A single string is converted to an array.
Omitting the key uses the site setting, falling back to the theme default. Set [] to disable actions for the main photo. Export variants use only their own explicitly configured actions and do not inherit main-photo settings.
GET /export: includes recorded user consent
Change date: October 21, 2026
Each item in the files array returned by GET /export now includes user_consent, matching GET /invitation and GET /search. Recorded decisions contain a boolean choice and their original UTC datetime; the field is null when no valid decisions are recorded.
Decisions are collected only for enabled, applicable consent questions. Both acceptance and refusal are returned, including theme-defined categories. Historical decisions and timestamps remain available if a category is later disabled or removed; unanswered categories are omitted.
Invitations: configurable consent and custom categories
Change date: October 18, 2026
POST /invitation now accepts config.consent with independent enabled and mandatory flags for use_general, use_marketing, enhance_genai, and additional categories declared by the active theme. Partial overrides inherit omitted flags from site and theme defaults. Site settings provide a Consent section for the three base categories.
New invitations save their resolved consent settings at creation, so later site or theme changes do not alter them. Older invitations without saved consent settings use current site settings with theme inheritance. An empty request object retains defaults; explicitly set enabled: false to disable a category.
The user_consent objects returned by GET /invitation and GET /search now support custom categories and preserve historical decisions for categories removed from the theme. Each decision still contains a boolean choice and a UTC datetime; no recorded decisions still produces null. Integrations should accept additional category names.
GET /export: includes image variants
Change date: October 4, 2026
Each photo returned by GET /export now includes a variants array for additional exported versions, such as images with different dimensions or backgrounds. Each variant contains suffix, file_name, file_type, and Base64-encoded file_content.
Variants are included automatically according to the export configuration; no new request parameter is needed. The top-level image fields continue to hold the main exported image. When no additional variants are available, variants is an empty array. Variants do not count as separate pagination records.
Save the main image and all required variants before calling DELETE /export, which also removes the associated variants.
Authentication: system accounts replace the legacy API role
Change date: October 2, 2026
Use a static API key assigned to a system account to authenticate your integration. System accounts cannot log in to the web interface. Existing users with the legacy api role are migrated to system accounts, and that role is removed. Account restrictions, endpoint roles, and site permissions still apply. POST /token is reserved for the Photo Collect app and requires a valid app secret in addition to user credentials. Use GET /token with your API key or access token to resolve your account details; no app secret is required.
Photo uploads: normalize embedded colour profiles to sRGB
Change date: September 27, 2026
Incoming photos with embedded colour profiles are converted to sRGB during processing, then stored without the embedded ICC profile. This affects images submitted through POST /photo and PUT /photo, helping preserve consistent colours in processed and exported photos.
GET /appsettings: authentication required
Change date: September 25, 2026
Reading and writing device settings through /appsettings now require a valid API key or user token. Send your credentials using the supported authentication headers.
API filters: reject malformed filter values
Change date: September 24, 2026
The customer_no, site_code, and invitation_key filters now accept only strings or flat lists of strings. Nested arrays and other invalid value types return HTTP 400 with INVALID_FILTER. The legacy customer_numbers filter must be a comma-separated string.
Search, exports, and uploads: enforce limits and access checks
Change date: September 24, 2026
GET /search and GET /export now normalize invalid or below-one pagination values to their defaults and guard against export pagination overflow. The maximum search limit and export page size remain 100.
Invitation and search responses include the uploaded_with record only when your credentials grant access to the related invitation, and stop circular replacement references. PUT /photo checks site permissions before returning success for an already-uploaded invitation.
Invitations and search: include user consent in responses
Change date: September 16, 2026
GET /invitation and GET /search now include user_consent. Recorded choices can cover general photo use, marketing use, and GenAI enhancement, using the keys use_general, use_marketing, and enhance_genai. Each recorded choice contains a boolean choice and a UTC datetime; the field is null when no consent is recorded.
Photo uploads: no longer support legacy SVG signatures
Change date: September 11, 2026
POST /photo and PUT /photo no longer convert SVG signatures to PNG. If you send SVG signatures, switch to a supported bitmap signature format, such as PNG.
Photo processing: queued GenAI enhancement and configuration changes
Change date: September 10, 2026
GenAI enhancement can run through a server-side queue. Invitation and search responses can expose the additional photo_status values queued, processing, and processing_failed. Allow processing to finish before expecting an export.
Invitation configuration accepts image_enhance_genai_enabled and image_enhance_genai_prompt when the feature is available. A non-empty prompt enables enhancement unless it is explicitly disabled. The site configuration returned by GET /site and GET /photocode no longer exposes provider API keys, enhancement prompts, model settings, or the legacy relighting configuration; image_enhance_genai_enabled remains available.
DELETE /invitation: retryable response while a photo is busy
Change date: September 10, 2026
DELETE /invitation can now return HTTP 409 with errorcode: PHOTO_BUSY when a photo mutation lock cannot be acquired. The response includes retryable: true, retry_after_ms: 2000, and the Retry-After: 2 header. Retry the deletion after the indicated delay.
Invitation configuration: validate face zoom factors
Change date: August 24, 2026
The face_zoomfactor invitation override now accepts -1 or values from 1.0 through 3.0. Unsupported values are discarded during configuration normalization instead of being applied. This affects configuration supplied when creating invitations.
JSON responses: include a Content-Length header
Change date: August 13, 2026
JSON responses now include a Content-Length header containing the encoded response size in bytes. Response bodies retain their existing JSON structure.
GET /health and GET /usagereport: provide health and usage data
Change date: August 6, 2026
GET /health provides application and dependency update timestamps. Authenticate with an API key or user token. GET /usagereport provides per-site and total counts for uploads, exports, failures, deletions, and SMS segments. To access usage reports, use an account with the admin or reporting role.
Usage reports accept from and to dates in YYYY-MM-DD format and default to ten calendar days including today, using the configured reporting timezone. Invalid dates return INVALID_DATE; a start date later than the end date returns INVALID_DATE_RANGE.
Invitation configuration: preserve first-gate overrides independently of QC
Change date: July 10, 2026
The firstgate_checks_enabled override is now governed by the first-gate feature setting instead of the quality-control setting. Invitation creation no longer drops this override solely because manual quality control is disabled.
Invitation configuration: preserve optional boolean overrides
Change date: June 9, 2026
Null or empty boolean configuration values now preserve defaults instead of being interpreted as false. Individual firstgate_check_* overrides are retained unless first-gate checks are explicitly disabled. Likewise, signature and contact requirements are retained unless their corresponding request flags are explicitly disabled. This corrects configuration handling for POST /invitation.
Photo uploads: validate request size, Base64, and image content
Change date: June 4, 2026
POST /photo and PUT /photo now validate upload payloads before processing. Requests whose declared content length exceeds the configured request limit return HTTP 413 with UPLOAD_FAILED. Invalid or empty Base64 data, missing photos, and unsupported image types return INVALID_IMAGE.
The Base64 decoder also restores spaces to + characters to support form-encoded uploads.
POST /photo: optional first-gate checks can be softened
Change date: May 27, 2026
POST /photo now passes the soften_firstgate_checks option to photo processing. When enabled, optional first-gate checks are disregarded while hard checks remain enforced.
Invitation configuration: supports a first-gate enablement override
Change date: May 20, 2026
The invitation configuration accepted by POST /invitation supports the firstgate_checks_enabled boolean override. Configuration normalization removes dependent options when their parent feature is disabled. See the June 9, 2026 entry for corrected handling of omitted flags.
API timestamps: explicit timezone offsets and consistent expiry formatting
Change date: May 18, 2026
Invitation, search, export, and token timestamps are now formatted consistently as ISO 8601 values using the authenticated user's timezone, with UTC as the fallback. Stored timestamps and token-expiry checks use UTC.
The token_expires value returned by POST /token now uses an ISO 8601 timestamp with an explicit timezone offset instead of a database datetime string. Parse timestamps with their supplied offsets. Non-expiring API keys continue to have a null expiry.