Lesson Learned from Standardizing APIs In Hypergrowth Startup

Photo by Tingey Injury Law Firm on Unsplash

Background Story

I work in one of the fastest-growing startups in Indonesia at Xendit as API Product Manager. Xendit is one of the leading payment gateway in Indonesia and Philippines and we offer payment solutions for businesses to accept payments (Credit Cards, QR codes, eWallets, etc), disburse funds (Disbursements, Payout, etc), and other solutions suite mostly via API

  • We have established API design guidelines to record all Xendit API design styles and standards
  • And most importantly, some of our APIs have been refreshed based on customers feedback to provide a simple, consistent, and delightful experience

API Standardization Challenges

There are lots of challenges we faced to get to the state we’re currently at. I’ll group challenges into 3 main areas (sorted by highest complexity)

  • Didn’t possess the skills to design quality APIs
  • Unclear ownership and decision making to define standards
  • Unclear how long will it take to standardize items
  • Unclear when standardization will take in-effect
  • Unclear who will coordinate rolling forward standardization compliance for legacy APIs and when
  • Didn’t know how to fit tools in the standardization process
  • To solve for Technology: use openAPI, Swaggerhub, Stoplight, or Google Document

Setting Up API Standardization Process From 0 to 1

Setting up any processes from 0 to 1 is challenging and setting up one for API standardization has no exception

Use global standards. Don’t reinvent the wheel

Standards increase predictability and provide a great user experience. To quickly define API standards, we want to use existing global standards from ISO standards or RFCs available on the web to save time and research costs. Example of global standards are as follow:

Define organizational standards. Identify decision-makers

There were some areas left to be standardized and are unique per organization/company, for example, parameter naming, status naming, error messages, etc. There is no global standard for these areas. These standards are domain-specific per market, industry, product, user segment, or any other domain.

  • No one wants to take the lead to be the tie-breaker to resolve different arguments/perspectives
  • Product Group Standard: Few or all product teams within the same group share the same concepts. Example: Money-in payment methods. Democratic vote across products within the group.
  • Local Standard — Multiple Groups: Few or all product groups have the same concepts that need to be standardized. Example: Money-in and Money-out teams have amountconcept. Democratic vote across groups.
  • Global Standards — API and market agnostic: Product, industry, and market agnostic standards. Example: Error Structure. API Team as decision-maker.
Snapshot of Standardization RACI framework

Timebox decision making and provide transparent timeline

Once I have identified decision-makers, I will work with decision-makers to make standardization decisions. Before I start working on a standardization item, I timebox standardization period usually at a maximum of 1 month. This means a decision must be made on the particular item in no more than 1 month.

In proposal item followed by estimated time to standardize it

Endorse start early behavior

Defining standards takes time to research and make decisions. Although timeboxing provides visibility to stakeholders, things move really fast in a startup company.

Conclusion

Setting up API standardization is important to provide predictable, consistent, and delightful experience to customers and allow teams to design and produce quality APIs. But there are variables we’ll need to consider that are “less fancy” and tend to be overlooked specifically in the process of setting up the standardization process.

  • Define organizational standards. Identify decision-makers early will help you to run decision-making meetings efficiently
  • While working on making standardization decision, provide a transparent timeline so stakeholders are aware of the process and can plan accordingly
  • Finally, in a hypergrowth startup where everything moves really fast, we’ll need to be flexible to make decisions in a short period of time. Endorsing starting early behavior to teams gives time to make quality standardization decisions

Product Manager at Xendit. Alumni of ITB Informatics Engineering. Building payments infrastructure for SEA. Common sense, empathy, compassion, and mindfulness