Backend/API Developer Needed — Private Backend Foundation for Paid Order Intake + Job System

We are building the private backend foundation for a WordPress-based AI video production service. The public website, customer order form, uploads, checkout, and payment flow are handled separately in WordPress, Gravity Forms, and WooCommerce. This backend begins after payment, when WordPress sends a signed paid-order webhook to the private backend. This is Phase 1 only. This phase does not include Grok, OpenAI, ElevenLabs, automatic Director Module automation, AI/video generation, final assembly, final video delivery, or customer portal features. The goal is to build the secure private foundation that real paid customer orders will pass through before production. We need a backend that can: receive a paid order from WordPress verify the order really came from our site reject forged, replayed, duplicate, or invalid requests validate the payload field by field store order/customer/script/selection data in structured records rehost customer uploads into private storage create production jobs and script segment records provide an operator/admin view with permitted non-secret fields only protect private/proprietary production content from public, WordPress, and operator access prepare clean connection points for later AI/video-generation modules Core requirements: Backend structure Separate backend service outside WordPress Own backend database Own private file storage Backend must not be a WordPress plugin WordPress should not query the private backend directly WordPress sends a signed outbound webhook after successful payment Paid-order intake gate The backend needs one controlled intake gate for paid orders. Required: webhook receiver HMAC signature verification timestamp validity window replay protection idempotency / duplicate-order handling support for key rotation or a clear key-rotation process immediate logging/recording of incoming attempts clear refusal of invalid requests The system must handle cases such as: valid paid order bad signature altered payload duplicate webhook delivery replayed old request invalid or incomplete payload Payload validation The backend must validate the incoming order packet field by field. The payload will include roughly: customer/order data payment/order reference package selection people count product/no-product branch selected scene/template code selected performance style code selected voice option code script text speaker labels where applicable customer notes uploaded file metadata pricing/word count/segment information acceptance/consent fields Validation errors should clearly identify which field failed and why, so the WordPress developer can fix the issue without vague back-and-forth. Data model / records Please create linked records for: incoming webhook attempts customers/order metadata orders uploaded assets jobs script segments job status/history audit trail / important actions placeholder catalogue records for template/style/voice codes A paid order should become a production job with linked script segments and linked private assets. Script segmentation The backend should store the script and create script segment records according to agreed counting/segment rules. The segment count must match the pricing logic used on the website. The operator should be able to review segment data later. Private file handling Customer uploads may include face images, product images, background images, reference files, and optional voice samples. Required: download/rehost uploaded files from WordPress into private backend storage backend production must not depend on temporary WordPress file URLs uploaded files must not be publicly reachable file access should use authenticated or short-lived links include a retention-window mechanism or documented setup for 30/60/90 day retention treat face/customer-uploaded files as sensitive data Operator/admin panel Create a login-protected operator/admin view. Minimum operator view: job list job detail page customer/order metadata needed for production package/template/style/voice codes script and segment information uploaded assets or private access links job status/history Important: the operator view must show only permitted non-secret fields. Private/proprietary content must not be exposed through the operator view. Private/proprietary boundary The backend must separate: public website data customer/order data operator-visible production data private/proprietary internal production content Private production logic, prompts, style-pack contents, Director Module text, and internal mappings must be protected server-side and denied by default. For Phase 1, dummy/placeholder proprietary content is fine. Real proprietary content does not need to be loaded yet. What matters is that the protected boundary exists and can be tested. Website/backend coordination The WordPress developer needs a clear contract to build against. Please include: webhook endpoint details required headers/signature method payload schema example valid payload example error responses mock/test endpoint or simulator logging/debug information for failed webhook attempts written handoff notes for the WordPress developer The goal is that the website developer can test the webhook without waiting for real customer orders. Testing and acceptance Please include practical acceptance tests. At minimum, we should be able to verify: a valid paid order creates exactly one job duplicate webhook delivery does not create a second job bad HMAC signature is refused expired/replayed request is refused invalid payload returns field-level errors uploaded files are rehosted privately original WordPress file URLs are no longer needed for production private file access is protected or short-lived operator can view permitted job information operator cannot see restricted/proprietary fields backup is created backup restore is tested another developer could understand the handoff documentation Documentation / handoff At completion, deliver: source code repository deployment notes environment variable list database/schema notes webhook contract documentation payload validation notes backup/restore notes basic operations guide acceptance-test checklist handoff notes sufficient for another competent backend developer to take over later Possible stack We are open to your recommended stack, but please explain why. Possible options include: Python/FastAPI + PostgreSQL + private object storage Node.js + PostgreSQL + private object storage Supabase/Postgres, self-hosted or managed, if justified Please do not propose this as a WordPress plugin. The backend should be separate from WordPress. Not included in this phase: AI/video generation Grok integration OpenAI integration ElevenLabs integration automatic Director Module final assembly delivery routing customer portal advanced analytics multi-operator role system full production automation Please provide: Fixed price Timeline Estimated hours Recommended stack Milestone breakdown What is included What is excluded Acceptance tests for each milestone What hosting/accounts/licences are required Similar experience with signed webhooks, private storage, job systems, admin/operator panels, queues, or sensitive data Whether you can coordinate directly with the WordPress developer on webhook testing We have a detailed redacted backend developer packet available for shortlisted candidates. Please only apply if you have experience building secure backend/API systems, not just WordPress forms or simple webhook integrations.