Dashboard embed codes and the API

TomKelleher · April 2022

A quick two-in-one question about the API and making dashboards embeddable.

Is it possible to use the API to see the embed code for a dashboard?
Is it possible to change a dashboard from "Embed options = OFF" to "Embed options = Public" using the API?

Many thanks!

[Deleted User] · April 2022

It is possible, but involves some risk. The endpoint to activate an embed token for a dashboard is not officially documented. Even though you can always see it by inspecting the UI with developer tools in the browser, there is not yet a process where breaking changes from future releases would warn you that your scripts might eventually stop working:
Yes. The same api call in the screenshot will let you set the "publicLink" attribute as "off", "public", or "private"

[Deleted User] · April 2022

Screen Shot 2022-04-28 at 12.29.57 PM.png

[Deleted User] · April 2022

It is possible, but involves some risk. The endpoint to activate an embed token for a dashboard is not officially documented. Even though you can always see it by inspecting the UI with developer tools in the browser, there is not yet a process where breaking changes from future releases would warn you that your scripts might eventually stop working:
Yes. The same api call in the screenshot will let you set the "publicLink" attribute as "off", "public", or "private"

[Deleted User] · April 2022

TomKelleher · May 2022

Thanks for this. Very helpful to know it's possible.

But your URL and mine in Postman are rather different. This is my best "translation" of working GET ("https://api.domo.com/v1/pages/1388365081") to yours (which starts with "custom-emea.domo.com?")

Not working, of course.

What is "custom-emea.domo.com"? I've tried "https://arenacx.domo.com" but that doesn't help. I've tried using the same OAuth authentication (which DOES work for my "api.domo.com" calls) but it doesn't help here. I've changed to Basic Authorization using the client ID and secret, but keep getting this new error message:

"Full authentication is required to access this resource"

Suggestions? What am I missing? I know I have the client id and secret right, because they work in Postman for OAuth, and have all possible scopes assigned.

TomKelleher · May 2022

Can anyone help me out here? @chrishaleua ?

[Deleted User] · May 2022

Thanks for the mention Tom. custom-emea.domo.com is just another instance. It is the one I happened to be working in at the time. The way you replaced it with your instance was the correct first step.

Authenticating with a client ID and secret is actually used more for the different contexts of our fully documented endpoints on developer.domo.com. In this undocumented example, you would actually want to authenticate by logging in to your instance and referencing the cookie from your active session.

[Deleted User] · May 2022

@TomKelleher To ensure we are building the best solutions for you, can you help me understand why you would prefer to manage embed tokens programmatically rather than using the UI. Were you already aware of the Domo Everywhere page in admin where all embed token statuses can be changed in bulk?

TomKelleher · May 2022

Thanks for the clarification...

I want to do this because our biz model will have us creating multiple new dashboards per week, or even per day, so it's going to be arduous and error prone to climb into the UI each time, set the embed factors for each by hand, collect the codes by hand, and copy/paste them into our portal's backend database. I don't want anyone tasked with that. Plus, the person who will use our backend tools to assign the dashboard to our portal accounts, will not be a Domo user. I don't want them having access to Domo proper just to do this simple task.

Thanks for the pointer to the Admin Domo Everywhere screen. (I had clicked to the "Domo Everywhere" screen itself, and found it was just links to YouTube, but not providing any functions. Didn't know about the Admin screen.) This tool might be of some use in the future, but doesn't solve my immediate problem.

Our intended workflow is that:

Our data team sets up a new dashboard
They alert us of the name and/or ID, and which of our customers it is for
Our portal admin team uses a tool we create to query the Domo API to view data about that dashboard
If it is already embeddable, they get the code. If not, they make it embeddable, then get the code.
They use that code to configure the customer's access.

TomKelleher · May 2022

@chrishaleua

I decided to start where you did, and looked at the dev tools for my browser. I'm doing the same (I think) to GET the current state of the dashboard with Postman, but I always get this response:

{

"status": 401,

"statusReason": "Unauthorized",

"path": "/api/content/v1/pages/embed/1409253488/state",

"message": "Full authentication is required to access this resource",

"toe": "78WAL6CQZG-2TD4T-3SRFN"

}

I have no trouble using Postman for the public API, so I don't know what authentication info is missing.

I did notice that I have 8 headers in my Postman request, while in your screen shot you have 22! Are you bringing some cookies or other browser payload over to Postman? (If browser headers are needed to call this API, then that might be a hard-stop for me.)

[Deleted User] · May 2022

Yes. That is correct. Public documented APIs use the client ID and secret from developer.domo.com. However the undocumented APIs in this example use the header based auth from your active session in the instance. You definitely do not need as many as I do. I just switch between instances often.

Why would the header based auth method be a hard stop for you? While we continue to collect feedback from you, the ideas to potentially make this easier are being tracked in DOMO-261772

TomKelleher · May 2022

Thanks for your continued help with this...

What I need to be able to do is wire up a server-side HTTP client to be able to hit these undocumented APIs and generate and get these embed codes. To do that, I need to know what headers I need to have in that HTTP request, and how to generate those headers.

For instance, is there a "/token" endpoint where I would input my username and password? Or input my access key and secret key, to get a token that I put in the header? Because this server-side routine will need to create a session...there will rarely be a "current" session.

I see it can be done (from your screen shots) but not how you got to a state where it can be done.

(Ignore my comment about the hard-stop. I thought you meant that to do this in Postman, you need to log in via browser, go into the dev tools, get a token there, etc. My server-side routine won't be logging into an actual browser.)

TomKelleher · May 2022

For instance, just now I finally got it to work in Postman...but had to bring my browser's cookie over to do so. How do I replicate this using a server-side HTTP client?