The Crossref Curriculum

Troubleshooting submissions

On this page, learn more about:

Learn more about becoming a DOI detective to help rid the world of bad metadata.

Error and warning messages

DOIs that return a Warning status in your submission logs have been deposited, but may need extra attention. A Failure status means that either a particular DOI has not been deposited, or the entire deposit file was unable to be processed due to some error.


Warning Meaning Solution
Added with conflict The DOI was deposited; however, there was already another DOI in our system with identical metadata. This often occurs when an article is published ahead of print and deposited with no page numbers Review DOIs with warnings and resolve all conflicts

Errors: system checks

When processing a metadata deposit, we do a number of checks to prevent the introduction of bad data to our system.

Error Meaning Solution
Record not processed because submitted version: xxxxxxx is less or equal to previously submitted version (DOI match) The timestamp in this deposit file is numerically smaller than the timestamp in a previous deposit for this same DOI. Review and edit the timestamp included in the deposit. Timestamps can be found by reviewing past deposits, in the depositor report, or by retrieving the DOI’s metadata record
User with ID: {0} can’t submit into handle, please contact the Crossref admin The handle system username and password assigned to this prefix is incorrect in the Crossref system This is usually a clerical error. Please contact Support and include the submission ID in your email
User not allowed to add records for prefix: {0} The username that was used to submit this deposit does not have permissions to deposit DOIs beginning with this prefix Confirm that you are using the appropriate account and prefix. If you’re still having trouble, please contact Support and include the submission ID in your email
All prefixes in a submission must match (DOI[{0}]) All DOIs included in a single deposit submission must have the same prefix, regardless of ownership Revise submission, and split the single file into multiple deposits, each with a single prefix. Then resubmit the new deposit files
title “{title}” was previously deleted by a Crossref admin The title record being deposited or updated was deleted from our system, usually at the publisher’s request Review your title and compare to previous deposits for that type of content. If you’re still having trouble, please contact Support and include the submission ID in your email
user not allowed to add or update records for the title “{title}” The Crossref account that was used to submit this deposit does not have permissions to deposit for this title Review title to confirm that you are using the appropriate account and prefix. If you’re still having trouble, please contact Support and include the submission ID in your email
ISSN “12345678” has already been assigned to a different title/publisher/content type The ISSN, title, or ownership of your deposit does not match the title information we have on record Review your ISSN and compare to previous deposits for that title. Refer to the ISSN error help document. If you’re still having trouble, please contact Support and include the submission ID in your email

Errors: some common validation and processing errors

Error Meaning Solution
[error] :286:24:Invalid content starting with element {element name}'. The content must match '(("": item_number) {0-3}, ("": identifier) {0-10}) This is an example of a parsing error being reported in the log file. Since this output comes directly from the Xerces parser the actual message will vary depending on the error Review file at line / column indicated (in this example: line 286 column 24), edit, and re-submit. If you’re still having trouble, please contact Support and include the submission ID in your email
org.jdom.input.JDOMParseException: Error on line 312 of document file:///export/home/resin/journals/crossref/inprocess/395032106: The content of elements must consist of well-formed character data or markup Unacceptable markup in file Review the file as indicated, correct, and re-submit
[fatal error] :1:1: Content is not allowed in prolog Characters precede the XML declaration. This is almost always a Byte Order Mark (BOM) which most often occurs when word processing programs are used to edit XML files Open file in a text or XML editor and remove characters (usually ). If the encoding is shown as UTF-8 With BOM, change this to UTF-8 or UTF-8 Without BOM. Then resubmit the deposit. invalid byte 1 of 1-byte > UTF-8 sequence (0x92) There is a badly encoded character. Locate and correct the bad character encoding Learn more about using special characters in your XML
java.sql.SQLException: ORA-00001: unique constraint (ATYPON.NDX1_CIT_RELS) violated Two files containing the same DOIs have been submitted simultaneously. The system attempts to process both deposits, but only one deposit will be successful. The unsuccessful deposit will generate this error Review DOI metadata to be sure it was updated correctly
java.lang.NullPointerException Most often this means a citation-only deposit or multiple resolution resource-only deposit has been uploaded as a metadata deposit (or vice-versa) Resubmit deposit as DOI Resources or doDOICitUpload. If this does not apply to your deposit, please contact Support and include the submission ID in your email
Submission version NULL is invalid Schema declaration is incorrect Resubmit with correct schema declaration
Invalid namespace/version Wrong operation type, or submitted file is not XML Submit with correct operation type

Common ISSN and ISBN errors

In order to prevent duplicate records, and to ensure that DOIs are being assigned by the appropriate member, our deposit system includes certain checks on ISSNs and ISBNs. When you submit the very first deposit containing metadata for a given title, a title record is created in our system. This record includes the title, ISSNs or ISBNs, (optional) title-level DOI, content type, and the member. In all subsequent deposits, the title, ISSNs or ISBNs, and (if included) title-level DOI must match this record exactly.

You might encounter the following errors, which indicate issues with the ISSN, ISBN, or title record.

Title record discrepancy error

ISSN “{ISSN}” has already been assigned to a different title/publisher/genre

This error indicates the ISSN(s), title, or publisher in your deposit do not match the data we have on record for that ISSN.

To verify the data in the title record with a given ISSN, please search for that ISSN on the Crossref title list. If there are any discrepancies between the title, ISSN(s), publisher or content type that need to be updated, please contact and include the submission ID for your deposit.

Title ownership error

ISSN “{ISSN}” has already been assigned to a different publisher {publisher name}({publisher prefix})


ISBN “{ISBN}” has already been assigned to a different publisher {publisher name}({publisher prefix})

This error indicates that the title you are depositing is owned by another member/prefix. If you are the correct member for the title being deposited, please follow the procedures indicated in establishing and transferring ownership to have the title record transferred to your member/prefix.

Invalid ISSN or ISBN error

ISSN “{ISSN}” is invalid


ISSN “{ISSN}” is invalid

This error indicates that the ISSN or ISBN in your deposit is incorrect. All valid ISSNs and ISBNs use a check digit which is algorithmically validated by our deposit system. If your deposit fails with this error, please verify the ISSN or ISBN, and resubmit the deposit with the correct number.

Notification callback service

Notification callback is a service you can use to notify you when a submission log is available for a metadata batch query, or Cited-by query submission. Notification is provided in the form of a HTTP(S) URL where the log can be retrieved. If the notification callback service is enabled, you will no longer receive submission log emails.

How the notification callback service works

The callback will be an HTTP(S) request to a URL (notify-url) provided by the member with all data relayed via HTTPS headers. The notification specifies the availability of the result, some context of the request, and an HTTP(S) URL from which to get the result. ​The submission log may then be retrieved using the HTTP(S) URL.

The headers use the simple name and value structure; that is, the value has no additional structure that divides it into parts. To ensure that all Unicode values can be accommodated all header values will be UTF-8 encoded.

When the notify-url is used the following HTTPS headers are provided:

  • CROSSREF-NOTIFY-ENDPOINT: the notify-endpoint (Required)
  • CROSSREF-EXTERNAL-ID: the id given by the member with regards to the request. For metadata deposits, for example, it is the value of the doi_batch_id element (Optional)
  • CROSSREF-INTERNAL-ID: the id given by Crossref with regards to the request (Optional)
  • CROSSREF-RETRIEVE-URL: the URL for the member to use to retrieve the request’s result. Since the HTTPS header value is UTF-8 encoded, the URL will contain no URI encodings. For example, an Á will not be encoded as %C3%81
  • CROSSREF-SERVICE-DATE: the date and time stamp of the service request. Learn more about format specification in RFC 2616.
  • CROSSREF-RETRIEVE-URL-EXPIRATION-DATE: the timestamp after which service result is no longer available at the given retrieve-url.

Setting up an endpoint

You’ll need to set up and register an endpoint to receive callbacks.

  1. Create an endpoint using cURL:
curl -s -D - "\
  1. Test your endpoint:
curl -s -D - "\

After a few minutes your end-point will receive a callback with your test payload message. 3. Contact us to activate the service - we’ll need:

  • your endpoint info (notify-endpoint and notify-url)
  • the services you’re activating the service for (metadata submissions, batch querying, Cited-by alerts)
  • the username and/or DOI prefix you’ll be using.

Make sure you inform us of any changes to your endpoint: if a message fails to send we will retry for up to a week after which you will no longer be able to receive it.

Example of a notification

For the submission 1368966558 the notification would be as follows (new lines have been added between header name and header value to improve readability):

Fri, 11 Jul 2014 21:08:24 GMT
Fri, 18 Jul 2014 21:08:24 GMT

Querying for past callbacks

The notification callback service can be queried for past callbacks. The query is implemented as an HTTPSservice.(Access control and limits to end-points and time frames TBD).

The query takes 3 criteria, the notify-endpoints, an inclusive from timestamp, and an exclusive until timestamp. All timestamps use the ISO 8061 format YYYY-MM-DD’T’hh:mm:ss’Z, for example, 2014-07-23T14:43:01Z.

The query results in a JSON array of callbacks. For example, querying for the single endpoint “1CFA094C-4876-497E-976B-6A6404652FC2” returns:

   "notify-endpoint": "1CFA094C-4876-497E-976B-6A6404652FC2",
   "external-id": "apsxref:7ca42f54-093f-11e4-b65b-005056b31eb6",
   "service-date": "2014-07-14T21:08:24Z",
   "retrieve-url": "",
   "retrieve-url-expiration-date": "2014-07-11T21:08:24Z",
   "audit": [
       "notify-url" : "",
       "date" : "2014-07-14T21:09:00Z",
       "explanation": "http status 200"
   "notify-endpoint": "1CFA094C-4876-497E-976B-6A6404652FC2",
   "external-id": ...

A flat structure is used to aid processing the result as a stream. There is no order defined.

The audit item is a record of attempted callbacks. It details the notify-endpoint’s notify-url used at the time of the callback, the timestamp of the callback, and the HTTPS status of the callback. If more than one attempt has been tried then the audit array will contain multiple elements; there is no order defined.

The query service is currently available at:

The usr and pwd are your Crossref username and password. The ENDPOINT value is a notify-endpoint or a space separated set of notify-endpoints.

Glossary of notification callback service terms

  • notify-url: the URL that the member provides and is used to notify them of the availability of a service request’s result. How the URL is provided to Crossref will depend on the service.
  • notify-endpoint: an opaque token used to select a notify-url. The token will be anonymous and difficult to guess. The notify-endpoint is provided by the member. The notify-endpoint is associated with one notify-url (many notify-endpoints can be associated with the same notify-url).
  • retrieve-url: the URL that Crossref provides that is used by the member to get the service request result.
  • notify-payload: the data that specifies what service request this notification is for. This payload will use HTTPS headers so as to be HTTPS method-neutral (such as POST, PUT).
  • retrieve-payload: the service result. Each service will define its own result content-type (that is very much like what would be sent in email today).
  • notification-authentication: This is the method of authentication Crossref will use with the notify-url. Credentials are provided by the member.
  • retrieval-authentication: This is the method of authentication the member will use with the retrieve-url. The credentials are provided by Crossref.

Last Updated: 2020 April 8 by Laura J. Wilkinson