Hello Msommer,

I have followed your Steps to reproduce and am getting the same result.  Investigating now, and will be in touch soon.

Status Update:

I have been unable to find a cause and have reached out to Senior Engineers for support. I expect that sometime tomorrow we will be able to identify what is causing the failure and provide a ETA when we expect it to be fixed.

Thank you for your patience.

Thanks Michael, 

I appreciate the updates!

Msommer,

Can you try again now? I believe we have resolved the issue, but am not absolutely sure its the one affecting you.

Hello Michael,

I am still getting the 404 not found. 

Hmmm, very strange. We are getting inconsistent behavior. Continuing my investigations.

Are you now getting the expected results? 

One thing to note. For this api call, I am entering a dummy origin parameter.

When I inspect the returned JWT, it looks correct, but would passing the jwt/token to this api with some dummy origin result in a NOT FOUND? 

Also, side question about this api. Are there any document side effects associated with this call such as permissions mutations or the doc being published as a result of calling this API for a particular document? 

`Not Found` should only be returned if the `document` or the `embed` can not be found. I believe there is an issue with the data-store on our side causing the issue. That is under investigation.

No, there are no side-effects with the calls themselves. Creating an embed and embedding cause no change in permission to the documents in and off themselves. Where you post the embed and what users do on the document in the embed could affect access, but these API calls themselves do not.

Thanks!

Hey Msommer, we believe we have been able to identify the issue. The command listed in the API docs is unfortunately misconfigured and there is a small error in the documentation as well that would have prevented the iframe from working properly. I’ll list out the details of that here while we work on the fixes.

The documentation for the embedded viewer has the iframe’s src parameter wrapped in angle brackets like so 

<iframe
  src='<https://lucid.app/embeds?token=:token>'
></iframe>

It should not contain the brackets and look more like the following 

<iframe
  src='https://lucid.app/embeds?token=:token'
></iframe>

The other issue is in the Try It feature for the embedded viewer documentation. It has the url listed as 

https://api.lucid.co/embeds

This is incorrect. It should be the following

https://lucid.app/embeds

For now, I would recommend testing the embed iframe in some form of sandbox environment that lets you add custom html with the fixes I described above instead of the Try It feature in the documentation. Something like W3Schools html sandbox for example.

We are working on fixes to the documentation to remedy those issues. In the meantime, if you run into any additional issues please let us know. 

Thanks for the response, this is helpful!

I have been building something in a sandbox environment and will be testing soon.

I would like to confirm the following.

You mention the embed viewer API Try it feature should point to `https://lucid.app/embeds`, is this just for the documentation or should I also be pointing to this endpoint in the application I am building?

Also is the endpoint correct for these API’s?

https://developer.lucid.co/v1.0/reference/createembed

https://developer.lucid.co/reference/documentembedstoken

https://developer.lucid.co/reference/getorexportdocument

The `https://lucid.app/embeds….` is the URI that I would use for both testing and for the application you are building.

There is a long form explanation for this, but the short answer is yes. The other endpoints you listed are correct with regards to their URL. The embedded viewer is a unique case where the `api.lucid.co` URI is not used in favor of the `lucid.app` counterpart. 

Please let me know if that answers your question and if you run into any additional issues.