Release Notes¶

v0.16.0¶

Date: 2025-10-29

Overview (v0.16.0)¶

This release upgrades our API specifications to OpenAPI 3.1, enhancing validation for job requests. This includes more flexible syntax validation for emails and URLs, and improved phone number validation.

Improvements (v0.16.0)¶

OpenAPI v3.1 We have upgraded all Modigie API specifications to OpenAPI 3.1.
- Details: Before finalizing the schema for our JobV2 resource, we wanted to take advantage of OpenAPI 3.1 improvements. As a result, the validation of job requests may be more rigorous in some cases.
Advanced syntax validation The updated API specifications no longer strictly require format: email or format: url in the JobV2 request schema, even when a job type needs a valid email or URL.
- Details: Under typical schema validation, a job request with any invalid email addresses or URLs would be rejected before Modigie could perform its more valuable syntax validation. Since the Modigie Integration for Cloud Pub/Sub API is designed for a broad range of business needs, we perform an advanced syntax validation. This allows you to see which email addresses or URLs are valid or invalid in the job results. In practice, Modigie can now process a job as long as some required properties are valid, instead of discarding the entire job because of a single invalid element.
Phone number validation We have improved our advanced validation of phone numbers. We already validate if a phone number is valid, possible, and to which country it belongs. You will now see a new presumedPhoneType field. For countries where the phone type can be inferred from the number alone, this is a very reliable signal. For other countries, such as those in the NANP (e.g., United States, Canada), this is a best-effort determination. While the phoneType from a full phone number verification is a stronger signal, presumedPhoneType is useful for more tolerant use cases like data diagnostics or deciding programmatically if additional verification is needed.

Other Changes (v0.16.0)¶

JobV2 reference The Schema spec documentation has been updated.

v0.15.1¶

Date: 2025-09-26

Overview (v0.15.1)¶

This maintenance release fixes a bug with our internal analytics.

Other Changes (v0.15.1)¶

Data streams with microsecond precision As the performance of our underlying databases has improved, we have added microsecond precision to the datastream for our analytical platform. This change eliminates ambiguity and expands the precision of our analytics.

v0.15.0¶

Date: 2025-09-25

Overview (v0.15.0)¶

This maintenance release improves our internal Continuous Delivery (CD) processes.

Other Changes (v0.15.0)¶

Cloud Run and Cloud Endpoints managed by IaaC We have used Infrastructure as Code (IaaC) to manage nearly all Google Cloud resources since the launch of our real-time engine. However, our Cloud Run and Cloud Endpoints gateway services were managed separately. With this release, all compute resources are now incorporated into our IaaC stacks, resulting in more efficient and reliable deployment processes.

v0.14.1¶

Date: 2025-09-23

Overview (v0.14.1)¶

This maintenance release improves the robustness of our service by addressing idempotency issues.

Bug Fixes (v0.14.1)¶

Idempotency During the preview, we discovered idempotency issues in some edge cases that affected our analytical capabilities but not customers. We have refactored the idempotency behavior of all event-based endpoints, their corresponding database transactions, and data streams to resolve this.

v0.14.0¶

Date: 2025-09-16

Overview (v0.14.0)¶

This maintenance release improves our internal repository management.

Other Changes (v0.14.0)¶

Improved automation of repository management This release introduces an automated workflow for managing the repository lifecycle. When a repository is created, a series of asynchronous tasks are now automatically triggered to provision the necessary infrastructure. This automation handles status transitions from connecting to connected and from activating to active, which streamlines the setup process and reduces manual intervention. This is a foundational step toward enabling self-service repository management.

v0.13.0¶

Date: 2025-09-02

Overview (v0.13.0)¶

This maintenance release improves our disaster recovery capabilities.

Other Changes (v0.13.0)¶

Point-in-time recovery We have enabled Cloud Firestore's built-in Point-in-Time Recovery (PITR) for up to 7 days on all relevant databases that store customer data.
Database backups We have replaced our proprietary cyclic backup solution with Cloud Firestore's built-in backup functionality for all databases.

v0.12.0¶

Date: 2025-08-13

Overview (v0.12.0)¶

Breaking Changes (v0.12.0)¶

Breaking Change: source removed from SMS email addresses

We introduced changes that requires action on your part to ensure your prototype continues to work as expected.

Reason for the change:

Whenever Modigie verifies or appends a mobile phone number, you may also get a list of related SMS email addresses for the mobile number. In previous releases, these SMS email addresses also had a source property. Since SMS email addresses can't be provided by you and are appended by Modigie only, we removed the source property from SMS email addresses.

Impact:

The preview environment now correctly returns payload.phoneNumbers[].smsEmailAddresses without a source property.

The source property was only removed from SMS email addresses. Normal email addresses that you provide in payload.emailAddresses[] can still have a source property and you can utilize it as usual.

Migration guide:

To adapt to this change, you need to update your code as follows.

Where you consume job response messages, do not expect the source property in payload.phoneNumbers[].smsEmailAddresses. SMS email addresses are never provided by you. You can track the source of the phone number in payload.phoneNumbers[].source as usual.

BeforeAfter

Example with the source in SMS email addresses:

response-body.json

{
  "payload": {
    "phoneNumbers": [
      {
        "callWindows": [],
        "compliance": null,
        "phoneNumber": {
          "country": {
            "alpha2": "US",
            "alpha3": "USA",
            "num3": "840",
            "officialName": "United States of America",
            "title": "United States"
          },
          "e164Format": "+12025550100",
          "intlFormat": "+1 202-555-0100",
          "isPossible": true,
          "isValid": true,
          "ituCountryCode": 1,
          "natlFormat": "(202) 555-0100",
          "userFormat": "(202) 555-0100"
        },
        "phoneType": "mobile",
        "rating": {
          "numberActivity": {
            "code": "high",
            "score": 89
          },
          "numberNameMatch": {
            "code": "high",
            "score": 89
          },
          "score": 89
        },
        "rels": [
          "business"
        ],
        "smsEmailAddresses": [
          {
            "emailAddress": {
              "isDeliverable": true,
              "isSyntaxValid": true,
              "normalFormat": "2025550100@vtext.com",
              "rfc882Format": "2025550100@vtext.com",
              "userFormat": "2025550100@vtext.com"
            },
            "rels": ["sms"],
            "source": null
          }
        ],
        "source": {  // (1)!
          "objectId": "RECORD1",
          "objectSystem": "mobile-phone",
          "objectType": "Contact",
          "propertyName": null
        }
      }
    ],
    ...
  },
  ...
}

The source of the phone number itself is not affected by this change.

Example where the source property is removed from SMS email addresses:

response-body.json

{
  "payload": {
    "phoneNumbers": [
      {
        "callWindows": [],
        "compliance": null,
        "phoneNumber": {
          "country": {
            "alpha2": "US",
            "alpha3": "USA",
            "num3": "840",
            "officialName": "United States of America",
            "title": "United States"
          },
          "e164Format": "+12025550100",
          "intlFormat": "+1 202-555-0100",
          "isPossible": true,
          "isValid": true,
          "ituCountryCode": 1,
          "natlFormat": "(202) 555-0100",
          "userFormat": "(202) 555-0100"
        },
        "phoneType": "mobile",
        "rating": {
          "numberActivity": {
            "code": "high",
            "score": 89
          },
          "numberNameMatch": {
            "code": "high",
            "score": 89
          },
          "score": 89
        },
        "rels": [
          "business"
        ],
        "smsEmailAddresses": [
          {
            "emailAddress": {
              "isDeliverable": true,
              "isSyntaxValid": true,
              "normalFormat": "2025550100@vtext.com",
              "rfc882Format": "2025550100@vtext.com",
              "userFormat": "2025550100@vtext.com"
            },
            "rels": ["sms"]
          }
        ],
        "source": {  // (1)!
          "objectId": "RECORD1",
          "objectSystem": "mobile-phone",
          "objectType": "Contact",
          "propertyName": null
        }
      }
    ],
    ...
  },
  ...
}

The source of the phone number itself is not affected by this change.

Affected components:

Any client application that consumes job response messages.

Improvements (v0.12.0)¶

Synthetic Verify Mobile is available Verify if the given phone number is an active mobile phone number and belongs to a given lead or contact. Learn more.
- Details: For testing free of charge, please request this feature for your synthetic Pub/Sub repository. If you'd like a push subscription (callbacks) for the job responses of this type, please let us know the endpoint URL.
Synthetic Verify Employment is available Verify if a lead or contact is still employed at the target company and what the current job title is. If the person left the target company, try to provide the current employer, job function and when the person has left the target company. Also all tasks as in Enrich LinkedIn. Learn more.
- Details: For testing free of charge, please request this feature for your synthetic Pub/Sub repository. If you'd like a push subscription (callbacks) for the job responses of this type, please let us know the endpoint URL.
New event code in events.verifyEmployment.code Job types that include employment verification, i.e. Enrich Mobile & Verify Employment (enrichMobile) and Verify Employment (verifyEmployment), support the new event code verified_elsewhere which addressss use-cases where more nuance is needed.
- Details: See Event codes.
Quota control For every repository Modigie provides a pipeline that will manage all jobs before they are dispatched to the real-time engine. Now pipelines control the quota utilization and usage tracking per job type.

Bug Fixes (v0.12.0)¶

Synthetic job response For any synthetic job response with an employment verification, the payload.employment.position.verification.title will be present if available. In earlier releases, the synthetic endpoint only returned the verified current position in payload.employment.position.verification.title if you provided a current position in paylod.employment.position.title.

Resolution: The preview environment now correctly returns payload.employment.position.verification.title when available.

response-body.json

{
  "payload": {
    "employment": {
      "company": {
        "source": {
          "objectId": "personId1",
          "objectSystem": null,
          "objectType": null,
          "propertyName": "company"
        },
        "title": "Acme Inc.",
        "verification": {
          "title": "Acme Inc."
        }
      },
      "employmentEnd": null,
      "position": {
        "source": null,
        "title": null,
        "verification": {
          "title": "VP Foo Marketing"
        }
      }
    },
    ...
  },
  ...
}

Other Changes (v0.12.0)¶

Security patches: Fixing known vulnerabilities in dependencies. They couldn't be exploited and didn't affect users.
- Details: As we monitor our software supply chain for known vulnerabilities, we continously release security patches.
Documentation clarification: Various updates and clarifications in the documentation and examples.
- Details: Provided more examples and explanations on how the system handles synthetic requests. Information about the Onboarding process.
Documentation of schema:
- Details: Job V2 reference generated from our latest Open API 3.0 specification.

v0.11.7¶

Date: 2025-07-17

Overview (v0.11.7)¶

This release focuses on internal changes related to pipeline management.

v0.11.6¶

Date: 2025-07-11

Overview (v0.11.6)¶

This is a maintenance release.

v0.11.5¶

Date: 2025-07-04

Overview (v0.11.5)¶

This release focuses on internal changes related to pipeline management.

v0.11.4¶

Date: 2025-06-27

Overview (v0.11.4)¶

This is a maintenance release.

v0.11.3¶

Date: 2025-06-27

Overview (v0.11.3)¶

This release focuses on internal changes related to the release of the new Modigie Identity API.

v0.11.2¶

Date: 2025-06-23

Overview (v0.11.2)¶

This release focuses on internal changes related to pipeline management.

v0.11.1¶

Date: 2025-06-23

Overview (v0.11.1)¶

This release focuses on the documentation.

Other Changes (v0.11.1)¶

Documentation update:
- Overview renamed to Discover
- Get started moved to Discover
- New menu item Resources with Operations, Release notes
- Job V2 reference as sub navigation of Reference

v0.11.0¶

Date: 2025-06-20

Overview (v0.11.0)¶

Internal maintenance release that improves the management of Modigie Pub/Sub repositories and their job orchestration pipelines.

Improvements (v0.11.0)¶

Tenant infrastructure A Modigie Pub/Sub repository is automatically updated when its job orchestration pipeline is updated.

v0.10.1¶

Date: 2025-06-19

Overview (v0.10.1)¶

Internal maintenance release for the migration of the Modigie Identity API.

Improvements (v0.10.1)¶

Tenant infrastructure This release allows the Modigie Pub/Sub API to manage tenant-specific infrastructure through the new Modigie Identity API which replaces the previous Modigie Customer API.

v0.10.0¶

Date: 2025-06-12

Overview (v0.10.0)¶

This release focuses on the migration of the API specification from Swagger 2.0 to Open API 3.0.

What's New (v0.10.0)¶

API specification in Open API 3.0 format Our Swagger 2.0-based specification has been replaced with an Open API 3.0-based specification.
- Impact: Developers can now use more powerful tools to explore the REST resource schemas used by our API.
- Affected Components: Documentation.

Bug Fixes (v0.10.0)¶

Duplicate job ID in preview: Resolved an issue where duplicate job IDs were not being handled correctly in the preview environment.
- Resolution: The preview environment now correctly discards duplicate job requests with identical payloads.

Other Changes (v0.10.0)¶

Documentation clarification: Clarified idempotency behavior in the documentation.
- Details: Provided more examples and explanations on how the system handles duplicate requests.
Documentation of schema:
- Details: Job V2 reference generated from Open API 3.0 specification.

v0.9.5¶

Date: 2025-06-16

Overview (v0.9.5)¶

This release introduces a few schema changes that we have applied based on further exploration and feedback from beta users.

Breaking Changes (v0.9.5)¶

Breaking Change: Schema changes

We introduced changes that requires action on your part to ensure your prototype continues to work as expected.

Reason for the change:

In order to simplify the API surface and make it more future-proof we have decided to make a few changes to the schema.

Impact:

One property names has changed and your application needs to adjust the code that produces job request messages or consumes job response messages to use the new name. For a list of changed definition names that should not make code changes necessary, see below.

Migration guide:

To adapt to this change, you need to update your code as follows.

Where you publish requests and consume responses, rename the property employment.jobTitle → employment.position

Before:

Example with the old name employment.jobTitle:

body.json

{
  "payload": {
    "employment": {
      "company": {
        "title": "Acme Inc.",
        ...
      },
      "jobTitle": {
        "title": "Head of Engineering",
        ...
      }
    },
    ...
  },
  ...
}

After:

Example with the new name employment.position:

body.json

{
  "payload": {
    "employment": {
      "company": {
        "title": "Acme Inc.",
        ...
      },
      "position": {
        "title": "Head of Engineering",
        ...
      }
    },
    ...
  },
  ...
}

Affected components:

Any client application that publishes job request messages.
Any client application that consumes job response messages.

Improvements (v0.9.5)¶

Renamed definitions For improved client support and request validation, we are preparing to migrate our API specification from Swagger 2.0 to Open API 3.0. As part of these efforts, we have changed definition names that should not affect application code, but improve discovery and understanding.
- Us → DoNotCallOrTcpaUs
- RichSource → JobV2Source
- RichSourceObjectId → JobV2SourceObjectId
- RichSourceObjectType → JobV2SourceObjectType
- RichSourceObjectSystem → JobV2SourceObjectSystem
- RichSourcePropertyName → JobV2SourcePropertyName
- CompanyTitleNullable → JobV2CompanyTitleNullable
- CompanyTitle → JobV2CompanyTitle
- CompanyVerificationTitle → JobV2CompanyVerificationTitle
- CompanyVerification → JobV2CompanyVerification
- JobTitle → JobV2PositionTitle
- JobTitleNullable → JobV2PositionTitleNullable
- JobVerification → JobV2PositionVerification
- JobVerificationTitle → JobV2PositionVerificationTitle
- JobV2TitleRequest → JobV2PositionRequest
- JobV2Title → JobV2Position
- UrlOrNoneRequest → UrlRequestNullable
- UrlOrNone → UrlNullable
- EmailAddressV2Request → EmailAddressRequest
- EmailAddressV2 → EmailAddress
- PhoneNumberV2Request → ItuPhoneV2Request
- PhoneNumberV2 → ItuPhoneV2
- LocalityV2RequestNullable → LocalityRequestNullable
- LocalityV2Request → LocalityRequest

Bug Fixes (v0.9.5)¶

Architecture Diagram Typo: Corrected a minor typographical error in the architecture diagram within the documentation.
- Resolution: The diagram now accurately reflects the intended text.

Other Changes (v0.9.5)¶

Documentation Update: Updated the documentation regarding push vs. pull subscriptions.
- Details: Clarified best practices and considerations for choosing subscription types.