Help us improve!

Tell us how we could make the product more useful to you.

[WEBHOOK] Allow an optional callback_url parameter on the enqueue call, as an alternative to webhook_ids

Today webhooks must be pre-registered per model in the platform UI, and the enqueue call only accepts webhook IDs (webhook_ids). There is no way to give a URL at request time. This does not scale well for us: We have N models and several environments (local, dev, staging, prod), so we have to create and maintain N x M endpoints by hand in the UI, plus one per developer for local work. Each environment then needs its own MINDEE_V2_WEBHOOK_ID value to keep in sync, so configuration lives half in your UI and half in our code. For local development the tunnel URL (ngrok, localtunnel) changes regularly, so a developer has to go back into the UI and edit the endpoint every time.

Ismaile ABDALLAH 18 days ago

1

Completed

View API-Uploaded Documents in the Mindee Interface

We are very interested in Mindee and are currently evaluating your solution. At the moment, we are using Rossum in production, and we are testing Mindee to compare both platforms and potentially switch if the results are successful. There is one important feature that is currently missing for our workflow: the ability to view documents uploaded via API directly in the Mindee interface, similar to how documents can be reviewed in the Live Test. This capability is very important for our operational and support teams, as it allows easier verification, troubleshooting, and collaboration when processing documents programmatically. We would really appreciate it if this feature could be considered for your roadmap. Thank you for your work and support. Best regards,

vtp 5 months ago

3

Completed

Add createdAt / completedAt fields in /v2/jobs/{job_id} response payload

We are currently experiencing regular timeout issues when using the enqueue_and_get_inference method from the Mindee Ruby client. Switching to a webhook-based flow would require significant architectural changes on our side, which we would prefer to avoid for now. We noticed in the documentation that it is possible to configure polling_options to increase the timeout duration. However, while investigating how to fine-tune these options, we realized that the GET /v2/jobs/{job_id} endpoint does not return the job createdAt or completedAt timestamps. Without these timestamps, we cannot measure the actual processing time of a job and adjust our polling strategy accurately. Could you please consider adding the following fields to the /v2/jobs/{job_id} response payload? createdAt completedAt Please let us know if this information is already available through another endpoint or if there is a recommended workaround. Thank you in advance for your help !

Faks 6 months ago

4