GetVibe offers media generation through an asynchronous job API alongside its text model APIs. The media request path is not the same as OpenAI chat completions: submit a generation job, receive a job ID, and retrieve its status and result. Image, video, and audio/voice models have different inputs and billing units, so choose from the media model catalog rather than assuming one request shape works for every model.
Find a model and inspect its requirements
Use the media catalog and /v1/models?type=image,video,audio to see the media types available to your account. Check each model’s exact ID, accepted input, supported options, output format, and price unit. An image model may charge by output settings; video may depend on duration and resolution; voice models may bill by text length, duration, or another documented unit. Do not compare these prices as if all were text tokens.
gpt-image-2 is one image model in the catalog. Its model page and media docs list supported aspect ratios, resolution, and generation/edit options. Video models have their own inputs and can take longer. Voice features vary by model; confirm the current media listing before promising a particular operation in your UI.
Submit an image job
Keep the key on your server. This is the documented asynchronous shape for a text-to-image request: the prompt is a top-level field and generation options are inside opts.
curl https://getvibeapi.com/api/media/generate \
-H "Authorization: Bearer $GETVIBE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-image-2",
"prompt": "A clean editorial illustration of a developer desk, no text",
"opts": {"aspect_ratio":"16:9", "resolution":"1K", "mode":"text-to-image"}
}'Persist the returned jobId with your own user and task record. This request starts generation; it does not return the finished image body inline.
Poll or receive a webhook
For a small integration, poll the job endpoint at a moderate interval and stop when the job reaches a terminal state. States include submitting, processing, success, fail, and expired. Polling every few milliseconds adds traffic without speeding up generation. For production batches, configure the documented webhook and make the callback idempotent so duplicate deliveries do not create duplicate assets.
curl "https://getvibeapi.com/api/media/jobs/$JOB_ID" \
-H "Authorization: Bearer $GETVIBE_API_KEY"On success, retrieve the result URLs and copy the media to storage you control if it needs long-term retention. On failure, keep the job ID for support and show a useful error. Do not retry every failure: an invalid option will fail again, and a duplicate generation may incur another charge.
Video and voice need model-specific handling
For video, inspect the model’s duration, frame size, image-conditioning requirements, and supported options before submitting. Validate remote source URLs and ensure they are reachable. Keep job progress visible because rendering can take longer than text generation. Use the documented webhook flow for batches instead of holding an interactive page open.
For voice and audio, distinguish speech generation from transcription or audio understanding. They have different input and output modalities. Match the endpoint and payload to the model card, set text or duration limits where offered, and store returned audio in a format your player accepts. Do not promise that every media model can produce voice.
Budget and failure behavior
Check the media model’s current price before a batch and estimate in its actual billing unit. A text model price is not a proxy for image or video generation. Run one sample with the exact resolution, duration, or voice settings planned for production. Record job ID, model, options, duration, terminal state, and charged usage. Set a maximum batch size and manual review for expensive or customer-facing outputs.
Keep prompts and media URLs out of general logs unless your privacy policy permits them. Redact credentials, enforce upload limits, and avoid exposing private generated assets as public URLs. For edits, retain the original asset separately until the result is reviewed.
Checklist before production
- Confirm the exact model ID, modality, and input requirements.
- Keep the API key on the server.
- Use the documented top-level prompt and model-specific options.
- Persist job IDs and make polling/webhook handling idempotent.
- Define failure and expiration behavior.
- Budget by the model’s actual billing unit.
- Copy successful outputs to storage if they must persist.
Read media generation, media webhooks, and media models before shipping. The public model list and supported options can change; those pages and the live catalog are the reference for your account.
Handle source assets safely
For image-to-image or image-conditioned video, use the upload or URL method documented for that model. Confirm that a source URL is publicly reachable by the generation service and does not require your logged-in browser session. Avoid embedding long-lived signed URLs in prompts that can be copied to logs. Set upload size and content-type checks on your own application before accepting user files.
When generating from a user-provided image, preserve the original file and track consent and retention requirements. A generated result can contain recognizable source details; apply your product’s privacy and moderation rules before sharing it.
Design the user interface around job states
Show a submitted state after the job ID is returned, a processing state while the service works, and clear terminal states for success, failure, or expiration. Let users safely navigate away if the job continues asynchronously, then restore status by looking up your own stored job record. Prevent a double-click from submitting duplicate work by disabling the submit control or using your own idempotency guard.
For a batch, show completed, failed, and pending counts separately. A single aggregate spinner gives no clue whether a long video job is healthy or stalled. Keep a bounded polling backoff and switch to the documented webhook path when the batch grows.
Store results with a retention plan
Do not treat a returned result URL as permanent storage unless the media documentation says so. Download successful output into your storage bucket when long-term access is required, then save the new object ID in your database. Apply access control to generated files and define deletion behavior when a user removes a project.
Record model ID, options, prompt version, job ID, result object, terminal status, and billed usage. This makes a later support question answerable without logging the full sensitive prompt or exposing the media URL to everyone on the team.