Enable to v2 API access endpoints for members using custom software and more intelligent submission reports to diagnose easily

Hello,

I have been requested to enable v2 API access before (which is currently exclusive to OJS users only) - when we are applied to become sponsored organization and testing our content registration automation software. I’ve been following related GitLab issue about that but there’s no update about it. It would be nice to have allow us to use that API endpoints.

Another issue is that; is there any way to get “related DOI” for failed records when using XML deposits? For example:

<record_diagnostic status="Failure" msg_id="45">
     <doi>DOI not found</doi>
     <msg>Error in Journal Article (Author ORCID): ORCID "https://orcid.org/0000-0000-0000-0000" has invalid checksum</msg>
</record_diagnostic>

In that situation, related DOI is already found in posted XML but indicated after that invalidated tag, I think parser software throws that message when reading and validating that tag immediately and skips to next article without reading DOI tag line.

3 Likes

Hi @hdogan,

Thanks for your question, and welcome to the community forum! Thanks for posting.

Unfortunately, we don’t have any short-term plans to extend the Deposit API v2 beyond OJS. As an alternative, many of our users do deposit using HTTPS POST as documented here: https://0-www-crossref-org.libus.csd.mu.edu/education/member-setup/direct-deposit-xml/https-post/#00494. And, there is a simple Java program that can help here: https://0-www-crossref-org.libus.csd.mu.edu/education/member-setup/direct-deposit-xml/https-post/#00495.

As for your question about ‘related DOIs’, you can retrieve failed submissions from the admin tool using these instructions:

  1. Log in to the admin tool with your Crossref username and password
  2. Click the Submissions tab, then the Administration sub-tab
  3. Click Search at the bottom of the screen, and you’ll see a list of all past deposits for your account, from newest to oldest. [note: if you only want to search for failed submissions, you can filter using the ‘has error’ field in the Administration sub-tab (see screenshot below - in that screenshot, I have signed into my account and am looking for submissions with errors from the last week)]
  4. Click on the Submission ID number to the left of any deposit to access the Submission details , including the submission log for that deposit, or click on the file icon to view the file that was submitted.

Does that help? If your question is specific to the XML you are submitting, can you add that XML file to this thread?

Thanks in advance,
Isaac

3 Likes

Hello, sad to hear about your plan - I still couldn’t understand the reason but maybe you want to promote OJS. (We already analyzed OJS plugin source code but nothing found different than another software).

We’re already using HTTPS POST method (which is integrated to our own journal management software) for deposits. That method is not a same quality service with the OJS exclusive API but it works at the moment.

Anyway, we have no problem about getting/receiving failed submission logs. We already receive them via e-mail or as a HTTPS POST status request. As I indicated in my main post the major problem is that some of the failed items on those reports (record_diagnostic tags) does not include DOI numbers, like ORCID related error message example I given. So (sadly) we have to check manually those error messages then try to match the actual faulty record in deposited XML file . As a result we’re unable to automate error handling process in our software.

Best.

1 Like

Do you happen to have the submission ID that is throwing this error @hdogan ? I was reviewing this thread and realized the next best step is to research what we can do with some of the error messaging we return when errors like this are triggered. But, I’d need the submission ID of this example to confirm that.

Thanks in advance,
Isaac

Sure, here are some of them:

1504113223
1477036222
1470609392

Since HTTP POST error report always returns “DOI not found” error on every failed record (<doi> tag) - we are unable to match failed record automatically. So we already stop using HTTP POST method for deposits and manually upload and check if any errors then manually match that failed record. It become time consuming and tiring job since we manage multiple member/journal deposits.

This is why we request v2 API to be enabled for non-OJS users too. (we use our own journal management/manuscript submission software).

Thanks for these details @hdogan . I see your point. That would be much easier if we can include the DOIs in the error message. I have opened a Gitlab issue with our technical team to investigate what is possible. You may follow our progress here: As a member and registrant of ORCID metadata, I'd like ORCID-related errors to return the DOI in the error message (#652) · Issues · crossref / DEPRECATED User stories · GitLab

More as I have it,
Isaac