A quick two-in-one question about the API and making dashboards embeddable.
Many thanks!
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.
Can anyone help me out here? @chrishaleua ?
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.
@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?
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:
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.)
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
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.)
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?
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
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.
