Return trial expiration date in trial application response

Why are we doing this work

Currently, GitLab needs to call GitlabSubscriptions::TrialDurationService to determine the expiration date of a trial after applying for one. This service makes an additional call to the customers application, which is inefficient. By returning the expiration date directly in the trial application response, we can eliminate this extra call and improve performance.

Problem to solve

The trial application endpoint should return the trial expiration date in its response so that GitLab can use this information directly without needing to make a separate service call.

Proposal

Modify the trial application endpoint to include the trial expiration date (or duration in days) in the response payload. This will allow GitLab to display the trial expiration date immediately after a successful trial application without requiring an additional API call.

Implementation details

  • Add expiration_date or trial_duration_days field to the trial application response
  • Ensure the response includes all necessary information for GitLab to calculate and display the expiration date
  • Ensure new trial controllers is also updated (separate epic/project)

Related issues

This is part of a two-part change:

  • Customers: Return trial expiration date in response (this issue)
  • GitLab: Consume the expiration date from the response instead of calling TrialDurationService
Edited Feb 11, 2026 by Doug Stull
Assignee Loading
Time tracking Loading