Skip to content

Onboarding process

Once you have completed the data diagnostic on a sample batch and the business requirement analysis with our team, you should have a clear understanding of:

  • The possible contribution of our different Job types to your business needs.
  • The coverage and accuracy that your business can expect from our real-time engine in production.
  • The use cases where you want to embed the Modigie Integration for Cloud Pub/Sub API.
  • For each use case and job type, the tolerable turn around time (from request to completed response), expected monthly usage and maximum bursts during a month.
  • The technology stack that you will use to integrate with the API, mainly the programming language, hosting provider and platform or products that will run your application.

To programmatically access our real-time engine through a RESTful API, your application needs an exclusive Modigie Pub/Sub Repository. This is an instance of our Modigie Integration for Cloud Pub/Sub API that manages all configurations, jobs, and other data for your application. Modigie will provide you with repositories during onboarding and all related resources on our side.

The 4-Phase Onboarding Journey

To eliminate integration risk and accelerate time-to-value, the onboarding process is structured into four sequential phases:

Phase 1: Data Diagnostic & Requirement Analysis

We begin by conducting an offline data diagnostic on a customer-provided sample batch (CSV). Our engineering and data science teams review the diagnostic report together with your stakeholders to evaluate yield, accuracy, and match rates against the Modigie LiveRecord Engine. Together, we establish target use cases, latency requirements, and monthly volume tiers.

Phase 2: Quick Real-World Quality Test (Pilot Validation)

Before committing engineering resources to build a full custom integration, we provide an initial live Modigie Pub/Sub Repository configured with a low Job Dispatch Rate. During a live 1-hour pairing session with a Modigie engineer, your team uses our turnkey Quick Quality Test Utility to process an evaluation batch (< 500 records) directly against the live API. This provides immediate, empirical validation that the live Cloud Pub/Sub API produces the exact same high-precision data quality observed during the offline batch diagnostic.

Evaluation Scope

The Quick Quality Test Utility is strictly designed for one-off quality validation batches (< 500 records) during this phase. It is not intended for production usage.

Phase 3: Synthetic Testing & Custom Application PoC

Once data quality is confirmed, Modigie provisions a synthetic Pub/Sub Repository. Your engineering team uses this risk-free environment to design, build, and test your custom production client:

  1. Interactive Schema Exploration: Interactively test request and response schemas for all desired job types.
  2. Edge Case & Error Handling: Safely test request-level discards (DuplicateJobIdError, syntax validation failures), job-level failures, and lifecycle events.
  3. Architecture & Concurrency: Implement your optimal push vs. pull subscription strategy, backoff retries, queue throttling, and scalability patterns.
  4. Performance Verification: Confirm that your custom application operates robustly under simulated scale.

Note

Please note that a synthetic repository can't be used to run real jobs. It is designed for testing your application logic during implementation. See Synthetic Repository for more information.

Phase 4: Production Cutover & Quota Elevation

With your custom application tested and verified against the synthetic repository, we transition your application to production:

  1. Point your application configuration and service account credentials to your production repository.
  2. Elevate the Job Dispatch Rate on your production repository to match your contractual volume tier.
  3. Begin automated, real-time job processing in production with full operational monitoring.

Requesting access

  1. Choose the job types that meet your business needs.
  2. Inform Modigie which job types you would like to test.
  3. Based on your technical requirements, choose one or both of the subscription modes. Every job type gets a separate pull and/or push subscription.
    1. By default, we will provide you with a pull subscription where job responses can be pulled programmatically and which you can also pull interactively to debug manually. If you don't want a pull subscription for a job type, please opt out.
    2. If you want the job responses to be delivered via a push subscription, please provide us with the endpoint URL for each job type (however, you can use the same URL if you prefer).
  4. Send Modigie a list of the Google Cloud user accounts that will get the Cloud IAM permissions to create and rotate the private keys of the Application Account.

Example

Job types and subscriptions, one of push | pull | both:

  1. Enrich Mobile & Verify Employment - enrichMobile: pull
  2. Verify Employment - verifyEmployment: pull
  3. Verify Mobile - verifyMobile: push to URL https://www.example.com/callbacks/v2?job_type=verifyMobile

Confirmation from Modigie

Based on your request, Modigie will provide you with:

  1. The ID of your Modigie Org Account
  2. The ID of your Modigie Pub/Sub Repository and whether it is synthetic or real
  3. The full names of every Pub/Sub topic for job requests (one per job type)
  4. The full names of every Pub/Sub pull subscription for job responses (one per job type)
  5. The full names of every Pub/Sub push subscription for job responses (one per job type) and the endpoint URL to where it will send the callbacks
  6. The Application Account's service account email address for verifying the authenticity of pushed messages
  7. Your requested Google Cloud users will have access to the Application Account
  8. The current Job dispatch rate of every job type based on your expected monthly usage. Please refer to Quotas and limitations for more information.

The configuration will be shared with you as a PDF whenever it changes.

Configure your application

Configure your custom application, e.g. with environment variables so it has these values available when needed:

  1. The Google Cloud project ID that hosts all GCP resources that Modigie created for you (it's always the same project for an Org Account).
  2. One of your Google Cloud users visits the GCP Console to create and download a private key JSON file for the Application Account and transfers these credentials into a secure storage of your application.
  3. The Application Account's service account email address for verifying the authenticity of pushed messages
  4. For every job type:
    • the name of the Pub/Sub topic to publish job requests of this job type
    • the name of the Pub/Sub pull subscription to pull job responses of this job type