Dashboard embed codes and the API
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!
Best Answers
-
- 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"
0 -
0
Answers
-
- 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"
0 -
0
-
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.
0 -
Can anyone help me out here? @chrishaleua ?
0 -
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.
0 -
@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?
0 -
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.
0 -
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.)
0 -
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
0 -
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.)
0 -
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?
1 -
Full authentication:
https://www.youtube.com/watch?v=d2WAKIKpKlE&t=1s
https://www.youtube.com/watch?v=hRwrZABP8RE&list=PLUy_qbtzH0S6-5oDbx3BsIv2Xk-JxJxWi&index=14
Jae Wilson
Check out my 🎥 Domo Training YouTube Channel 👨💻
**Say "Thanks" by clicking the ❤️ in the post that helped you.
**Please mark the post that solves your problem by clicking on "Accept as Solution"3 -
This is PERFECT.
"I have the POWER!"
This is just what I was looking for. Learning a lot about Postman, too.
Have a great weekend.
2
Categories
- All Categories
- 1.7K Product Ideas
- 1.7K Ideas Exchange
- 1.5K Connect
- 1.2K Connectors
- 295 Workbench
- 6 Cloud Amplifier
- 8 Federated
- 2.8K Transform
- 97 SQL DataFlows
- 608 Datasets
- 2.1K Magic ETL
- 3.8K Visualize
- 2.4K Charting
- 710 Beast Mode
- 50 App Studio
- 39 Variables
- 668 Automate
- 170 Apps
- 446 APIs & Domo Developer
- 45 Workflows
- 7 DomoAI
- 33 Predict
- 13 Jupyter Workspaces
- 20 R & Python Tiles
- 391 Distribute
- 111 Domo Everywhere
- 274 Scheduled Reports
- 6 Software Integrations
- 116 Manage
- 113 Governance & Security
- Domo Community Gallery
- 31 Product Releases
- 9 Domo University
- 5.3K Community Forums
- 40 Getting Started
- 30 Community Member Introductions
- 103 Community Announcements
- 4.8K Archive