Your application produces job input¶

Your application identifies which jobs it needs to request from Modigie and then publishes the workload via a job-type-specific Pub/Sub topic.

Identify the need¶

Identify the need in your database for leads, contacts, or prospects that you want to validate, verify, or enrich.
If you want to budget the usage between different entities, for example, teams or customers, monitor the volume of workload that has been requested and charged for each entity, and respect the limits and quotas before sending the job requests.

Pick the job type¶

Your application selects one of the available Job types.

This is the of schemas for job requests of each type:

Make sure that, depending on the job type, your job request will have all required properties!

Tip

Your application may log occurrences where job requests have been skipped because required fields were missing.

For every individual attribute provided by your application, for example, phone number or email address, you can also provide a source reference to the original source of the data point. Modigie will return these values as is. This enables your application to digest the job result efficiently, as it can safely determine which exact record and field it needs to add, update, or delete. See RichSource.

Produce a unique request ID¶

Produce unique job identifiers as idempotency keys for any workload that has been identified, for example, a combination of job-type and lead ID and an increment. If you want to retry a job request, provide a new job ID. The request ID must be published as a Pub/Sub attribute named modigieJobRequestId.
If a job request is not discarded, the job resource is created with the modigieJobRequestId as the job's id.
Modigie will use your request ID to detect unintentional duplicates. A job request with the same identifier and exact fingerprint of the payload will not trigger a new job processing or charge, but your application will receive the job results again. If a duplicate request ID was used but with a different payload, Modigie will discard the job and return a Pub/Sub message with the attribute modigieJobDiscardReasonType = "DuplicateJobIdError".

Info

If a previous job execution completed without technical failure but did not yield the desired output, for example, the Modigie real-time engine could not append a mobile phone number for the given person, another request with a duplicate job identifier will not execute again.

Please refer to Job identifiers for more information.

Limit the time to dispatch¶

Your application can publish the job request with the Pub/Sub attribute modigieJobExpireAfter. With this value your application can control how much time the job can spend in the queue before being either dispatched to the real-time engine or canceled free of charge.

Choose a priority¶

Your application can set a priority for the job request. All your jobs in the queue with the same job type are dispatched by priority in descending order. This allows your application to prioritize specific jobs in the same queue. See Job priority.

Assign custom tags¶

Your application can attach custom tags to each job request. Modigie returns these tags as is in all job responses. See Custom Tags.

```json title="job-request.json"
{
  "payload": {
    "tags": [
      {
        "name": "campaign",
        "value": "2025-09-OUT"
      },
      {
        "name": "billing",
        "value": "00427"
      }
    ],
    ...
  },
  ...
}
```