Skip to content

API description checklist compliance review #66

Closed

Description

@anthorange

Problem description
This issue is based on the Camara Marketing “Checklist for API description review”:
https://github.com/camaraproject/Marketing/blob/main/documentation/SupportingDocuments/Checklist_for_API_description_review.md

The Know Your Customer Tenure API page reviewed:
https://camaraproject.org/know-your-customer-tenure/

The page has checklist compliance gaps for:

  • API Description (the image is only illustrative)
  • Use Cases (text format / missing GSMA Use Case Library links)
  • Benefits (text format)
  • Sub Project Wiki (incorrect prefix)

Expected action
Please update the Know Your Customer Tenure API documentation page so it matches the checklist by applying the following corrections:

  1. API Description
  • The image is currently illustrative and does not clearly represent a “typical use case” workflow/value for developers (as expected by the checklist).
  1. Use Cases
  1. Benefits
  • Benefit name should be in bold (none of them are).
  1. Sub Project Wiki
  • The correct prefix is "Sub Project Wiki:" (current prefix: "SubProject Wiki:")

Additional context
Checklist reference:
https://github.com/camaraproject/Marketing/blob/main/documentation/SupportingDocuments/Checklist_for_API_description_review.md

Reviewed page export:
https://camaraproject.org/know-your-customer-tenure/

Activity

  1. MarkusKuemmerle commented on May 8, 2026

    @MarkusKuemmerle
    Contributor

    Hello,

    the CAMARA outreach team is currently reviewing all the API descriptions to improve it and make it attractive for customers and developers. There is some confusion how to handle and solve the findings. I would like to give the following recommendations:

    • Findings in the text of API description, Use Cases, Benefits: These should be solved by the Sub Project, changes should be documented in the API description Wiki page, and then the Sub Project should open an issue in the Marketing repo to change the website. This follows the defined process description to change the website.

    • Findings in the visuals: The Sub Project should give instructions to improve the visuals following the criterias defined in the checklist. The instructions also can be included in the wiki page and addressed to the outreach team by issue in the Marketing repo. We plan to ask the LF creative team to generate new visuals for us based on these instructions.

    • Findings on the right column (with all the links): Reviewers should put these findings in the review xls and not in the issue. Sub Projects cannot solve it. The CAMARA outreach team is taking the findings from the xls and is changing the website.

    So please work on 1. and 2. and 3. and ignore 4. in the first comment above.

    Hope that helps, Markus

  2. albertoramosmonagas commented on May 19, 2026

    @albertoramosmonagas
    Contributor

    Hi @MarkusKuemmerle, @anthorange, thanks for the clarifications. I have prepared a proposal for review by the Sub Project owners (@camaraproject/tenure_codeowners) based on the Marketing checklist and your clarification on responsibilities: https://lf-camaraproject.atlassian.net/wiki/spaces/CAM/pages/808714246/Tenure+API+description+v2. The proposed updates are:

    1. Update the API description to make it more developer-centric and focused on the actual Tenure value
    2. Replace the current illustrative image with a workflow-style visual showing a typical developer use case: Tenure check before onboarding, authentication or risk decision.

    Suggested visual concept: The visual should show a developer workflow where an end user starts a sensitive digital action, such as onboarding, login, password reset, account recovery, credit application, high-value transaction or KYC verification; the business application calls the CAMARA Know Your Customer Tenure API through Open Gateway; the mobile network checks whether the phone number has had valid tenure with the current operator since the reference date provided by the API consumer; the API returns a privacy-preserving trust signal, tenureDateCheck: true/false, and optionally contractType where supported; and the business then applies a risk-based decision such as allow, step-up verification, manual review, reject, block, adjust risk score or request additional identity checks. The visual should present Tenure as an operator-verified mobile identity stability signal for onboarding, authentication, account recovery, credit risk, KYC and fraud prevention workflows, avoiding generic security/KYC imagery and avoiding any implication that the API directly verifies identity or exposes the actual line activation date.

    1. Update the Use Cases section and benefits section, but there is no clear Tenure-specific match on the GSMA Use Case library.
  3. MarkusKuemmerle commented on Aug 2, 2026

    @MarkusKuemmerle
    Contributor

    @albertoramosmonagas Please open an issue in the marketing repo when you're done to trigger us to update the website

  4. albertoramosmonagas commented on Sep 1, 2026

    @albertoramosmonagas
    Contributor

    We can close this issue because we've created a new one on the marketing repo to modify the current API description: camaraproject/Marketing#86

  5. MarkusKuemmerle commented on Sep 16, 2026

    @MarkusKuemmerle
    Contributor

    Website updated 16.09.2026

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions