This message was deleted.

I started putting together an unofficial doc for my own use. it’s pretty barebone at the moment; I’ve scrubbed the examples+schemas I inferred from responses until I can ensure there’s no sensitive info. https://github.com/skwaugh/secoda-openapi

Thanks Sawyer, we’re in the process of revamping our documentation which will combine integration, feature, and API documentation into one aggregated place. But I appreciate the “Unofficial documentation” that you’ve created in the meantime!

can be previewed here - https://redocly.github.io/redoc/?url=https://raw.githubusercontent.com/skwaugh/secoda-openapi/main/secoda-openapi.yml

Wow, impressive! @careful-application-95617, have you seen this?

This looks awesome, thanks for putting it together 🙌

Thanks Andrew. Looking forward to that! My main point of interest is to understand the Lineage feature, with the ultimate goal of creating a custom ‘table’ type to accommodate not-yet-supported integrations/resources and including those in the Lineage viz. from testing the API and digging into the Github revision history, I gather that that is not yet possible on the user’s end…but I have high hopes for future feature launches 😎

For what it’s worth, the way it works on the backend (which you’re correct is not exposed yet) is that we just take two resource id’s and we specify which is upstream and which is downstream and then we make the connection between the two. If we opened up an API with that specification would you find it useful? It would be a quick add.

If I could define my own arbitrary integration, i.e. a

custom resource

, and then create new tables, then 100% yes - that API that would be a massive benefit. The entire platform becomes extensible at that point

I see what you’re saying. This is aligned with the direction we’re moving towards where all “resources” from data sources are under one flexible data model instead of their own data models.