Module 6: FinTech and data products

View study sheet (PDF) View SQL cheat sheet (PDF)

Teaching this module? A facilitator guide adds a preparation checklist, timing cues, discussion guidance, slides, and a printable PDF.

This session treats ALT/FNDATA itself as the teaching case: how does a raw, messy, physical-world dataset such as auction and resale transaction records become a commercial data product with a schema, an access tier structure, and a REST API. Students examine the three access surfaces a real data vendor maintains (a no-code sandbox, documentation with a client library, and a production API) and discuss the product and business decisions behind each one, including why self-serve access and manually issued API keys serve different customer segments. The session closes with students sketching their own access-tier design for a hypothetical alternative data product, using ALT/FNDATA's structure as a reference point rather than a template to copy exactly.

Target course(s) and level

FinTech product design, data product management, or technology entrepreneurship course. Suitable for MBA students and graduate students in a technology management or product concentration; pairs well with Module 4 in a course that covers both the investment use case and the product-design perspective on the same dataset.

Learning objectives

By the end of this session, students will be able to:

  1. Describe the three access surfaces of a data product (no-code sandbox, documentation and client library, production API) and the distinct customer need each one serves.
  2. Explain the tradeoffs between self-serve access and manually issued credentials, using API key provisioning as a concrete example.
  3. Read and interpret a REST API's request and response shape, including endpoint, headers, filters, and pagination.
  4. Identify what a data dictionary and coverage browser contribute to a data product's usability, separate from the raw data itself.
  5. Design a basic access-tier structure for a hypothetical data product, justifying which tier gets self-serve access and which requires manual approval.
  6. (Extension) Issue a working API request using the reusable Python client and interpret the response envelope.

Prerequisites

An introductory course in product management, technology strategy, or entrepreneurship. No coding background is strictly required for the core session; the optional code extension assumes basic Python familiarity and comfort running a script.

Materials and access needed

  • Sandbox access at sandbox.altfndata.com, self-registered with a work or school email, auto-approved, used as the primary teaching artifact for the no-code tier.
  • Documentation site at docs.altfndata.com, including the quickstart, task-based tutorials, the Evaluation Guide at use-cases.html, and the downloadable client (altfndata_client.py).
  • For the optional extension: an instructor class API key requested from info@altfndata.com, distributed to student groups for the API demo segment only.
  • Projector or screen share for the instructor demo, and a whiteboard or shared document for the access-tier design exercise.

Session outline (90 minutes)

  • 0 to 15 min: Introduce the three access surfaces (sandbox, documentation, production API) and why a data vendor maintains all three rather than just one.
  • 15 to 30 min: Guided demo, sandbox as the no-code, self-serve tier.
  • 30 to 45 min: Guided demo, documentation and client library as the on-ramp to programmatic access.
  • 45 to 60 min: Guided demo, production API request and response shape, including the optional live code extension.
  • 60 to 75 min: Small-group exercise, students design an access-tier structure for a hypothetical alternative data product.
  • 75 to 88 min: Group share-out of access-tier designs.
  • 88 to 90 min: Wrap-up and homework assignment.

In-class demo (sandbox-first, no code)

  1. Open sandbox.altfndata.com and register with a work or school email. Point out to students that approval is automatic, which is a deliberate product decision to remove friction for the self-serve tier.
  2. Walk through the SQL editor, coverage browser, data dictionary, and schema tabs. Ask students which of these components exist purely to make the raw data usable, as opposed to storing new information.
  3. Run a simple query against the fine art data table to show the sandbox functioning end to end, using the query in the "Datasets and queries used" section below.
  4. Switch tabs to docs.altfndata.com and show the quickstart page, the task-based tutorials, and the Evaluation Guide at use-cases.html. Ask students who they think each of these pages is written for.
  5. Show the downloadable Python client (altfndata_client.py) and the runnable tutorials notebook without running any code yet, describing what each file contains.
  6. Explain the manual API key issuance process: keys are requested from the ALT/FNDATA team, not self-served, and discuss as a class why a vendor might gate the production API tier behind manual approval while leaving the sandbox open.
  7. (Optional extension, code) Using the instructor's class API key, project a single live request through the Python client that mirrors the sandbox query from step 3, and show the response envelope containing table, result_count, and data.
  8. Point out that result_count reflects only the current page of results, not the total match count, and discuss why pagination design choices like this matter for a product's API consumers.

Datasets and queries used

Dataset: fine art data (documented fields: designer, model, item_title, sale_date, usd_price_decimal, sale_estimates_high_usd_price, status, vendor, stock_ticker).

Sandbox SQL editor query used in step 3:

SELECT item_title, sale_date, usd_price_decimal, vendor
FROM all_fine_art_data
WHERE status = 'sold'
ORDER BY sale_date DESC
LIMIT 25;

Optional API extension, equivalent request body (POST /v1/tables/all_fine_art_data/query, header X-API-Key):

{
  "fields": ["item_title", "sale_date", "usd_price_decimal", "vendor"],
  "filters": [
    {"field": "status", "op": "eq", "value": "sold"}
  ],
  "sort": [{"field": "sale_date", "direction": "desc"}],
  "limit": 25
}

Corresponding response envelope shape, shown to students as-is:

{
  "table": "all_fine_art_data",
  "result_count": 25,
  "data": [
    {"item_title": "...", "sale_date": "...", "usd_price_decimal": 0, "vendor": "..."}
  ]
}

Discovery endpoints referenced in the demo: GET /v1/tables (lists available tables) and GET /v1/tables/{name}/schema (returns the field list and types for a given table).

Discussion questions

  1. Why might a data vendor make the sandbox self-serve and auto-approved while keeping the production API behind manual key issuance?
  2. What does the response envelope's separation of result_count (this page) from the actual total tell you about the design tradeoffs behind pagination?
  3. What is the purpose of a data dictionary and a coverage browser in a data product, separate from the underlying data tables themselves?
  4. If you were designing pricing tiers for this product, what would distinguish a tier meant for an individual analyst from a tier meant for an institutional desk running automated queries?
  5. What risks does a vendor take on by offering a no-code sandbox with real production data, rather than a sample or synthetic dataset?
  6. How would you decide which of your product's features belong in documentation and tutorials versus which belong in the tool itself?
  7. What would you want to measure to know whether your access-tier design is working, once real customers start using it?

Homework assignment

Each student or student pair designs a one-page access-tier proposal for a hypothetical alternative data product of their choosing (it does not need to relate to luxury goods or ALT/FNDATA). The proposal must define at least three access tiers, specify for each tier whether access is self-serve or manually approved and why, sketch the shape of one example API request and response for the top tier, and identify one risk of the proposed design, drawing an explicit comparison to at least one specific design choice observed in ALT/FNDATA's sandbox, documentation, or API during the session (for example, the choice to auto-approve the sandbox but manually issue production API keys). Deliverable: a one-page written proposal plus a simple diagram of the three tiers, submitted as a single PDF. Grading criteria: clarity and specificity of the tier design (30 percent), quality of the self-serve versus manual-approval justification (25 percent), correctness and realism of the sketched API request and response (25 percent), and thoughtfulness of the identified risk (20 percent).

Going deeper

Key terms

  • Access tier: a level of product access defined by what a customer can request and how much oversight is required to unlock it.
  • Endpoint: a specific URL path in an API that performs one operation, such as running a table query or listing available tables.
  • Response envelope: the wrapper object returned around the actual rows, here table, result_count, and data.
  • Pagination: retrieving a large result set in fixed-size pages using an offset, rather than requesting everything at once.
  • Schema: the list of fields and their types available on a given table, returned by the schema endpoint.
  • Self-serve: an access flow a customer completes without a human on the vendor's side approving each step.
  • Client library: reusable code, here a Python client, that wraps the raw API calls a developer would otherwise write by hand.
  • Filter object: a single condition inside an API request body, expressed as a field, an operator, and a value.

Common pitfalls

  1. Assuming result_count reflects the total number of matching rows rather than just the rows returned on the current page.
  2. Forgetting to advance offset between requests, so a script silently re-reads the first page every time.
  3. Treating the sandbox's auto-approval as evidence that the production API is equally open, when production keys are manually issued.
  4. Featuring or promising the AI natural language search capability, which is still in development and not part of the current product.
  5. Confusing the fields listed in one query's request body with the full schema of a table, and missing fields that exist but were not requested.
  6. Designing a hypothetical access tier without a clear reason why it is self-serve rather than manually approved, beyond habit.

Additional queries to explore

  1. Request the schema for all_watches_data (GET /v1/tables/all_watches_data/schema) before writing any query, to see the full field list available and compare it against the smaller set of fields used in the module's tutorials.
  2. Run a POST query against all_handbags_data filtering on designer and status together and sorting by usd_price_decimal descending, to see how multiple filter objects combine inside a single request body.
  3. Run the same query twice, the second time with offset set to the first call's limit, to see the pagination pattern in practice and why result_count alone never tells you the total number of matches.

Extension activities

  1. Have students sketch three example filter objects a customer in each of their proposed access tiers would realistically send, and note which endpoints, beyond query, a top-tier customer would also need (for example, schema or the table list).
  2. Ask students to propose how they would throttle or rate-limit a self-serve tier without requiring manual key issuance, and defend the tradeoff.
  3. Have a student pair run the Python client with the instructor's class key against a second table, such as all_jewels_gems_data, and compare the resulting response envelope to the fine art example used in class.

Connections to other modules

Module 2, data science and SQL, covers the query logic that sits underneath this API's filters and sort. Module 12, data engineering and the API, goes further into the technical build of the same product this session treats as a business case. Module 13, data ethics, quality, and coverage bias, matters here too, since whichever tier a customer pays for, the same coverage gaps in the underlying data still apply to the rows they get back.