How to create a Static Website Proof via the API | Community
Skip to main content
pcardno
pcardno
Level 2
July 4, 2023
Solved

How to create a Static Website Proof via the API

  • July 4, 2023
  • 2 replies
  • 1761 views

Hi all,

 

We're trying to integrate Workfront Proof directly into our web build process, where we have automated tooling to create translations of sites and want to initiate Proofs on all the pages, which are public.

 

We want to initiate a Workfront Proof of a static page, which you can do in the UI via the www.shareyourlink.com box, which then generates the following type of Document, with a Proof on it:

 

https://experienceleague.adobe.com/docs/workfront/using/workfront-proof/wf-proof-tech-corner/proof-types/create-status-web-proof.html?lang=en

 

I can create a Proof via the API, but only of an existing document, but I can't find anything in the documentation that explains how to create a Document that's actually a Static Website proof.

The documentation suggests, as far as I can tell, that we should sniff the network activity on the page to work out the Advanced Proofing Options, which isn't massively helpful, but doing so suggests that it's actually using a REST API on ProofHQ, rather than a SOAP API, which is again not massively helpful given that doesn't appear to be documented anywhere:

 

 

Unless that's a proxy onto the standard Workfront /upload REST API call:

 

 

So, I'm fairly stumped. Has anyone figured this out and got a pattern for it that they can share?

 

Thanks,

 

 

Paul.

 

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by pcardno

Just in case anyone stumbles across this post and wants to do the same thing, we did manage to solve it by using the ProofHQ SOAP API, and then an undocumented endpoint in the Workfront API, which we found by reverse-engineering the UI (although it might be quite a common approach).

 

We firstly create the Proof in ProofHQ, via SOAP. Then we use /internal/documents/bulkImportProof from the Workfront endpoints to create a Document under a Project, which brings in the relevant proof.

 

Here's the code, from node.js, to do it

 

Create the Proof in SOAP HQ, where name parameter is the name I want the Proof to have, and sourceName is the URL of the webpage to be proofed:

 

 

Then create the document in Workfront using the bulkimportproof:

 

 

 

 

Note that in the above we've already got a session ID from Workfront via the OAuth2 approach, and the project has already been picked via a simple UI that we built in our application.

Also note that we had to do multiple retries on the CreateDocument, as Workfront fails silently fairly often. It returns an object with a property called "data" where the value is a Document Object ID, but maybe 10-20% of the time it didn't actually create it. So we immediately go back to check if it's actually there.

 

So not too bad, in the end. I've create a video showing it all in action here:

 

https://paulcardno.com/adobe/Generative%20Proofs%20via%20the%20API.mp4

 

Thanks,

 

 

Paul.

 

 

 

2 replies

Madalyn_Destafney
Community Advisor
Madalyn_DestafneyCommunity Advisor
Community Advisor
July 27, 2023

Hi there, have you checked out this article on how to create a static web proof of web content? Wondering if this is actually what you need - https://experienceleague.adobe.com/docs/workfront/using/review-and-approve-work/proofing/create-proofs/generate-static-proof-website-other-web-content.html?lang=en

If this helped you, please mark correct to help others : )
pcardno
pcardnoAuthor
Level 2
July 28, 2023

Hi @madalyn_destafney - yep, that's how we know it can be done via the front-end. But we are trying to do it via the API.

 

We've managed to do it, so I'll add another post with details as to how.

    pcardno
    pcardnoAuthorAccepted solution
    Level 2
    July 28, 2023

    Just in case anyone stumbles across this post and wants to do the same thing, we did manage to solve it by using the ProofHQ SOAP API, and then an undocumented endpoint in the Workfront API, which we found by reverse-engineering the UI (although it might be quite a common approach).

     

    We firstly create the Proof in ProofHQ, via SOAP. Then we use /internal/documents/bulkImportProof from the Workfront endpoints to create a Document under a Project, which brings in the relevant proof.

     

    Here's the code, from node.js, to do it

     

    Create the Proof in SOAP HQ, where name parameter is the name I want the Proof to have, and sourceName is the URL of the webpage to be proofed:

     

     

    Then create the document in Workfront using the bulkimportproof:

     

     

     

     

    Note that in the above we've already got a session ID from Workfront via the OAuth2 approach, and the project has already been picked via a simple UI that we built in our application.

    Also note that we had to do multiple retries on the CreateDocument, as Workfront fails silently fairly often. It returns an object with a property called "data" where the value is a Document Object ID, but maybe 10-20% of the time it didn't actually create it. So we immediately go back to check if it's actually there.

     

    So not too bad, in the end. I've create a video showing it all in action here:

     

    https://paulcardno.com/adobe/Generative%20Proofs%20via%20the%20API.mp4

     

    Thanks,

     

     

    Paul.

     

     

     

      Terms & ConditionsAccessibility statement

      Loading footer...